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nére írott levél- 


A Microsoft meg- 
nyitotta lTludásbázisát 
az MIVE-k előtt 


zerötszáz MVP (Most Valuable 

Professional), azaz Microsoft 

technológiában jártas szakértő 
részére tartott csúcstalálkozót idén 
áprilisban a Microsoft az Egyesült 
Államokban, melynek keretében több 
fontos bejelentésre is sor került. A Mic- 
rosoft vezetői bemutatták az egyelőre 
próbaüzemben működő Community 
Solutions Content Program for Micro- 
soft Knowledge Base nevű programot, 
amely lehetővé teszi az MVP-k számá- 
ra, hogy a Microsoft termékekkel és 
technológiákkal foglalkozó Microsoft 
Tudásbázis (Microsoft Knowledge 
Base) részeként működő Community 
Solutions webhely számára tartalmat 
készítsenek. Új információk hangzot- 
tak el a 2003 októberében beindított 
Microsoft MVP Forráskód-licencprog- 
ramról is. A jogosult országokból ed- 
dig több mint 200 MVP szerzett licen- 
cet a Megosztott Forráskód Kezdemé- 
nyezés keretében, akik ezáltal hozzá- 
férhetnek a Microsoft vagyonának 
egyik legértékesebb darabjához, a 
Windows forráskódjához. 
A csúcstalálkozó keretében olyan új 
segítő és közösségi eszközöket is be- 
mutattak, amelyek új visszajelzési csa- 
tornát biztosítanak az MVP-k számára. 
Az ügyfelek ezeken keresztül nyújthat- 
nak be a termékekkel és azok funk- 
cióival kapcsolatos javaslatokat és 
megvitathatják a felmerült ötleteket 
még a termékfejlesztés szakaszában. 
A visszajelzések közvetlenül a Micro- 
soft adott technológiáért felelős cso- 
portjához futnak be, mely ezután rea- 
gál a legtöbb szavazatot összegyűjtő 
javaslatokra. 
A Microsoft a kilencvenes évek elején 
indította , el a Most  Valuable 
Professional (MVP) Award Programot, 
azzal a céllal, hogy elismerje a nagy- 
közönség azon tagjainak munkáját, 
akik idejüket és informatikai szakértel- 
müket a többi felhasználó megsegíté- 
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sére fordítják. Az indítás óta eltelt idő 
alatt folyamatosan nőtt a Microsoft 
MVP Award Program tagjainak száma. 
A kezdeményezés mára több mint 
2500 tagot tudhat sorai között, akik 63 
országot és 20 nyelvterületet képvisel- 
nek, ismereteik pedig több mint 70 
Microsoft-technológiára terjednek ki. 
Az MVP-k mélyreható és szerteágazó 
ismeretekkel rendelkeznek legalább 
egy Microsoft-termékről, és ismeretei- 
ket szívesen osztják meg másokkal. A 
legtöbb MVP több mint 15 éves tech- 
nikai tapasztalattal rendelkezik saját 
szakterületén, férfiak és nők egyaránt 
vannak köztük, a legfiatalabb 13 éves, 
a legidősebbek pedig hatvanas éveik 
közepén járnak. Vannak köztük publi- 
káló írók, webhelykezelők, ismeretter- 
jesztő előadók, oktatók és professzio- 
nális fejlesztők. Ha MVP nyújt techni- 
kai segítséget egy online vagy offline 
közösségben, a többiek és az ügyfe- 
lek azonnal tudják, hogy egy tapasz- 
talt és hozzáértő személytől kapnak ki- 
váló tanácsot. 

A díjakat a Microsoft technikai közös- 
ségének legkiemelkedőbb tagjai kap- 
ják, cserébe azért, hogy hozzájárultak 
több száz online és offline technikai 
közösség ismereteinek növeléséhez 
Microsoft nyilvános hírcsoportokban, 
külső működtetésű webes hirdetőtáb- 
lákon, webes naplókban és felhaszná- 
lócsoportokban, amelyek mind nagy 
népszerűségnek örvendenek a Micro- 
soft termékeivel, technológiáival és 
szolgáltatásaival kapcsolatban egy- 
mással kommunikáló felhasználók kö- 
rében. 

Magyarország tavaly csatlakozott a 
nemzetközi MVP Programhoz. Jelen- 
leg nyolc főből áll a hazai MVP-k köre, 
akik közül hatan vettek részt az ame- 
rikai csúcstalálkozón. 


b ttp://www. microsoft. com/mvp/ 


butp: //www.microsoft.com/communities/ 
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Automatikus mermrnória- 
gazdálkodás a .NET-ben 1. rész 


OBJEKTUMOK SZÜLETÉSE ÉS HALÁLA 


A .NET szemétgyűjtője, a Garbage Collector az esetek nagy 
többségében észrevétlenül és hibátlanul teszi a dolgát. Előfordul 
azonban, hogy ismernünk kell a GC belső működésének részleteít is, 
hogy alkalmazásunk hatékonyan tudjon együttműködni vele. 


Fejlesztésmenedzsment 
módszertanok 


SZEMPONTOK ÉS NÉZŐPONTOK 


Az informatikai cégek különbözőképpen reagálnak, 
hafejlesztésmenedzsment módszertanokról kérdezzük őket. 
Egy részük azonnal rávágja az alkalmazott metodika nevét 

és fő jellemzőit, míg a másik véglet némi bizonytalanság után közli, 
hogy náluk ilyesmire nincs szükség, hiszen mindenki érti a dolgát. 


Uzletiintelligencia-szoftverek 
MS SOL 2000 REPORTIÍNG SERVICES II. RESZ 


Az üzleti intelligencia minden vállalat életében nélkülözhetetlen, 
segítségével megalapozott döntéseket hozhatunk, amelyek sikeressé 
tesznek minket a piacon. Az üzleti intelligencia nem feltétlenül igényel 

egy teljes OLAP-ot vagy adatbányászatot, mint amilyenek az SOL Server 
Analysis Services-re épülő megoldások, de minden üzletiintelligencia- 
megoldásnak van egy közös eleme: a jelentések (report-ok). 


Kiszolgálópark üzerreltetése e. rész 
A VAS 


A kiszolgálók telepítéséről, használatáról, hibajavításáról sok cikket 
olvastam, a kiszolgálók üzemeltetéséről szóló információkat 

ellenben meglehetősen nehéz összeszedni. Ez a cikksorozat ennek 

a hiánynak a pótlására született meg. Ebben a fejezetben azt elemzem, 
milyen legyen és mire jó a kiszolgálóhardver: Egyáltalán: miért vegyünk 
kiszolgálóhardvert? 


vvindows szolgáltatások 2. rész 


MELYIKET HASZNÁLJUK ÉS MELYIKET NE? 


A szolgáltatásokkal kapcsolatban számos alapfokú 
és haladóknak szóló információt nyújtottunk 

a sorozat első részében. Most megpróbáljuk 
egyesével sorra venni egy frissen telepített 
Windows Server 2003 tartományvezérlő 
alapértelmezett szolgáltatásait. 











MVR-találkozó Amerikában 


ÚJDONSÁGOK A . NET FRAMEWORK 2.0-BAN 


A tavaszi amerikai MVFP-találkozón számos újdonságot hallhattunk 
a jövő technológiáiról. Cikkünkben elsősorban a Visual Studio 2005 
és a .(NET Framework 2.O(whidbey) újdonságairól számolunk be. 





Tippek § trükkök 


FÓKUSZBAN AZ SOL SERVER 2000 


Egy-egy trükk megismerése sokat segíthet a mindennapi munkában. 
Cikkünkben az SOL Server 2000 használatához adunk tippeket. 


Ami a hivatalos Microsoft 
tanfolyamokból kimaradt... 


EXCHANGE 2000/ Et 
EXCHANGE SERVER 2003 XI 


Az előző számunkban közölt cikk 
folytatásaként újabb Exchange- 
érdekességeket, tanulságokat 
ismertetünk. 





Vizsgák és minősítések 
MICROSOFT OKTATÁSI TÁJÉKOZTATÓ 
A Microsoft kínálatában több mint negyven féle technikai vizsga van, 
amelyeket a hivatalos Microsoft oktatóközpontokban lehet letenni. 


Összeállításunkban részletesen ismertetjük a Microsoft vizsgák 
és minősítések rendszerét. 


Dr VVatson 


NE HIGGY A LOGNAK! 


Mármint a tűzfalak logjának. Ebben a cikkben alaposan utánajárunk 

annak a bosszantó jelenségnek, amikor egy tűzfalgazda kiszúrja, 

hogy egy távoli IPR-címről bizonyos TCP-portokat , feszegetnek"; vagy 
netalán portscannelést hajtottak végre. Azt hihetnénk, a támadó 
személyének vagy helyének felkutatására a legjobb információforrás 

a tűzfal naplófájlja. Az ottani IP-cím alapján rövid kutatást végezve kiderül, 
hogy a www.érdektelen.hu webszerver a támadó, ami gazdátlanul lóg 

a neten, láthatóan ép és egészséges, nincs feltörve. Elkövető tehát nincs. 


Ez hogy lehet? 
ET G 23200 a aa B 











Automatikus 
memóriagazdálkodás 


a NET-ben 


OBJEKTUMOK SZÜLETÉSE ÉS HALÁLA 


A .NET szemétgyűjtője, a Garbage Collector az esetek 


nagy többségében észrevétlenül és hibátlanul teszi a dol- 


gát. Előfordul azonban, hogy ismernünk kell a GC belső 


működésének részleteit is, hogy alkalmazásunk hatéko- 


nyan tudjon együttműködni vele. 


z alkalmazások korrekt erőforrás-kezelésének 

megvalósítása nem egyszerű feladat, komoly 

odafigyelést és gyakorlatot igényel. Az erőforrá- 
sok (és a hozzájuk tartozó memóriaterület) lefoglalásával 
és felszabadításával kapcsolatban elkövetett hibák nehe- 
zen azonosítható, rejtélyes hibákat okozhatnak az alkalma- 
zás használata során. 
A C4-4- nyelven fejlesztett programok esetében például a 
lefoglalt memória felszabadítását maga az alkalmazás kez- 
deményezi, az objektum számára new operátorral lefoglalt 
memóriát a megfelelő pillanatban a delete operátor segít- 
ségével fel kell szabadítani. A módszer természetesen tö- 
kéletes, egészen addig, amíg a megvalósítás hibátlan. Egy 
nagyméretű, több szálon futó alkalmazás esetében azon- 
ban egyáltalán nem könnyű a pontos kivitelezés, a memó- 
riában , felejtett" referencia nélküli objektumok memóriahé- 
zagokat (memory leak), a már felszabadított memóriaterü- 
letre való hivatkozás pedig futási hibát okoz. 


A COM komponensek a hivatkozások számlálásával oldják 
meg az általuk használt erőforrások felszabadítását. Az új 
hivatkozások megnövelik, a megszűnő referenciák pedig 
csökkentik egy számláló értékét. Ha a számláló értéke nul- 
la, akomponensre már nincs szükség, az lezárja az erőfor- 
rásokat, és felszabadítja a memóriát. A módszer gyenge 
pontja az, hogy a számláló beállítását a komponenshez 
csatlakozó ügyfeleknek kell(lene) kezdeményezniük. Ha ezt 
csak egy is elmulasztja, akomponens akár az idők végeze- 
téig is fölöslegesen a memóriában maradhat. 
Általánosságban is elmondható, hogy nem lehet tökéletes 
az a megoldás, ahol egy szűkös erőforrással (esetünkben 
a memóriaterülettel) való gazdálkodást maguk az erőforrás 
felhasználói irányítják. 


Minden objektum (és az általa megvalósított erőforrás) 
eléréséhez (használatához) a következő lépéseket kell el- 
végezni: 





m Memóriafoglalás (memory allocation) 

m A lefoglalt memória kezdeti értékének beállítása (me- 
mory inicialization) 

m A létrehozott objektum használata (memory use) 

m Az objektum lezárása (memory tear-down) 

mu A memóriaterület felszabadítása (memory freeing) 


A .NET által biztosított Garbage Collector (GC) teljes mér- 
tékben magára vállalja a hivatkozás nélkül maradt objektu- 
mok felkutatását és az általuk lefoglalt memóriaterület fel- 
szabadítását. Ha azonban az objektum a CLR hatáskörén 
kívül álló erőforrásokra is hivatkozik (unmanaged resour- 
ces), azokat a GC nem tudja megfelelően lezárni. Ilyen erő- 
források jellemzően az operációs rendszer által biztosított 
objektumok: megnyitott fájlok, hálózati vagy adatbázis- 
kapcsolatok stb. Ilyen esetben a lezárást elvégző kódot 
a programozónak kell megírnia az objektum Close, Dis- 
pose, vagy Finalize metódusában, a Finalize metódus 
megfelelő pillanatban való meghívásról viszont már a GC 
gondoskodik. 


Memóriafoglalás 

A .NET CLR-je minden erőforrást az adott folyamat számá- 
ra létrehozott menedzselt heap-en helyez el. A menedzselt 
heap hasonló a hagyományos programnyelvek által hasz- 
nált heap-hez, de az itt létrehozott objektumokat nem a 
program szünteti meg, a memória felszabadítása automati- 
kusan történik, ha az adott objektumra már nincs többé 
szükség. Hogy ezt megtehesse, a GC-nek természetesen 
tudnia kell, hogy mely objektumokra nincsen már szüksége 
a folyamatnak. A szükségtelen objektumok felderítésére 
használt algoritmust később részletesen meg fogjuk tár- 
gyalni. 

Előbb azonban tekintsük át, hogyan is zajlik a memóriafog- 
lalás a CLR felügyelete alatt. Amikor új folyamat indul el, a 
CLR folyamatos memóriaterületet (address space) foglal le 
a számára. Ez a memóriaterület a folyamat menedzselt 


heap-je. A heap-hez egy mutató is tartozik, ami a követke- 
ző létrehozható objektum kezdő címére mutat, kezdetben 
tehát az adott memóriaterület kezdő címére (base add- 
ress). Ez az állapot természetesen sohasem látható, mivel 
már az alkalmazást magát reprezentáló objektum is a 
heap-en foglal helyet. A folyamat objektumai által elfoglalt 
memúóriaterületet (bájtokban) a GC osztály statikus metó- 
dusával kérdezhetjük le: 


System. GC. GetTotalMemory (false); 


A false paraméter azt jelenti, hogy a GC nem fog begyűj- 
tést végezni a szabad memória meghatározása előtt, tehát 
a kijelzett értékben benne lesz a már használhatatlan ob- 
jektumok által elfoglalt terület is. 





szabad 
terület 


mutató 





3. objektum 
2. objektum 











1. objektum 


Memóriafoglalás a menedzselt heap-en 


A new operátor segítségével a heap-re helyezett objektu- 
mok mindig a mutató által meghatározott címre fognak ke- 
rülni (természetesen ilyenkor a mutató is módosul, hogy to- 
vábbra is a szabad hely kezdetére mutasson). Nincsen te- 
hát szükség a hagyományos heap-nél megszokott helyke- 
resésre, így a memóriafoglalás lényegesen egyszerűbb és 
gyorsabb. Azonban hogy a memóriafoglalás ilyen módon 
működhessen, azt kell feltételeznünk, hogy a mutató által 
meghatározott cím után mindig lesz elegendő szabad hely 
a létrehozandó objektum számára. Ennek biztosítása a GC 
feladata. 

Amikor az alkalmazás a new operátor használatával létre 
akar hozni egy objektumot, természetesen előfordulhat, 
hogy az objektum már nem fér el az adott címterületen. Ha 
a szabad terület kezdetét jelző mutató és a létrehozandó 
objektum méretének összege már a címtéren kívül esik, a 
heap megtelt. Ilyenkor lép akcióba a GC, felfüggeszti az 
összes szál futását, és eltávolítja a hivatkozás nélküli objek- 
tumokat. Ezután a megmaradt, még használható objektu- 
mokkal folyamatosan feltölti a címteret (elvégzi a hivatkozá- 
sok megfelelő módosítását is), tehát a címtér felső részen 
folytonos szabad címtartomány keletkezik, ahová az új ob- 
jektum már elhelyezhető. 

Az [1] címről letölthető mintaprogramot fogjuk használni a 
leírtak gyakorlati demonstrálására. A program konzol ala- 
pú, menüszerkezete a következő lesz: 


cs Parancssor - gc 





- Lefoglalt memória 

- A fő szál hash kódja 

- Szemetelés 

- Szemétgyűjtés 

- Finalization gueue 

- Újraéleszthető objektum 
- Objektum generációk 

- Gyenge referencia 

- Dispose használata 

- Kilépés 


A mintaprogram menüszerkezete 


Van egy AlapObjektum osztályunk, amelyből majd más 
osztályokat fogunk örökíteni. Kódja a következő: 


class AlapObjektum:Object ( 
protected String nev; 


public AlapObjektum(string s) 
( Console.WriteLine("Az alap objektum 
b osztályában megadott konstruktor fut."); 


-AlapObjektum() ( 
Console.WriteLine("Az alap objektum 
b osztályában megadott Finalize metódus 
4 TULSO: 
y 
§ 


A nev mezőt az utódok használják, minden objektumnak 
saját neve lesz, hogy létrejöttüket és megszűnésüket nyo- 
mon követhessük. 

Örökítünk belőle egy Szemet osztályt, ilyen objektumokat 
fogunk majd létrehozni és a GC segítségével megszüntet- 
ni. A Szemet osztály kódja a következő: 


class Szemet:AlapObjektum ( 
public Szemet(string s):base(s) ( 
this.nev-st". Szemét objektum" ; 
Console.WriteLine("A(z) "tH"nevt" 
b konstruktora fut."); 
k 


-Szemet() ( 
Console.WriteLine("A(z) ""nevt" 
hd Finalize metódusa fut."); 
Console.WriteLine("A Finalize szál hash 
kódja: " :Thread.CurrentThread. . 
b GetHashCode ( ) ) ; 


Az objektumokat létrehozó kód a Szemetelés menüpont se- 
gítségével indítható: 


static void Szemetel() ( 
Szemet sz; 
for (int i-O;ic1i00;ittr) 
sz-new Szemet(i.ToString()); 


h 


Minden objektum paraméterként egy sorszámot kap, ez 
lesz a neve, ez fog szerepelni a konstruktorok és destruk- 
torok üzeneteiben. 











Az új objektumok létrejöttét a konstruktorok képernyőre írt 
üzeneteinek alapján követhetjük nyomon, és a fenti kódból 
az is látható, hogy az objektumok létrehozásuk után azon- 
nal referencia nélkül maradnak. Ha a folyamat közben a 
heap megtelik, az új objektumok létrehozása átmenetileg 
leáll, és a GC automatikusan nekikezd a hivatkozás nélküli 
objektumok felszámolásának (az utoljára létrehozott objek- 
tum kivételével valamennyi ilyen). Ekkor a destruktorok 
üzeneteit láthatjuk a képernyőn. A takarítás végeztével foly- 
tatódik tovább az objektumok létrehozása. 

A Szemétgyűjtés menüpont segítségével magunk is bármi- 
kor elindíthatjuk a GC-t, és a destruktorok üzeneteinek se- 
gítségével megfigyelhetjük a , takarítás" folyamatát. A me- 
nüpont a következő metódust indítja: 


static void Collect() ( 
Console.WriteLine("A szemétgyűjtés elindult"); 
GC.Collect(); 
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A Lefoglalt memória menüpont segítségével ellenőrizhetjük 
a heap foglaltságát. 


A szemétgyűjtés algoritmusa 

Feladata elvégzéséhez a GC-nek képesnek kell lennie ar- 
ra, hogy az alkalmazás által már nem használható objektu- 
mokat azonosítsa. Ha ilyen objektumokat talál, az általuk 
használt memóriaterületet felszabadítja. A következőkben 
áttekintjük, hogyan történik a referencia nélküli objektumok 
azonosítása. 

Minden alkalmazás rendelkezik egy úgynevezett gyökér- 
készlettel (set of roots). A gyökerek gyakorlatilag olyan mu- 
tatók, amelyek a heap-en lévő objektumokat azonosítanak, 
értékük vagy egy objektum címe, vagy null. Az alkalmazás 
gyökérkészletéhez tartoznak az objektumokra mutató glo- 
bális és statikus adattagok, az adott szál veremterületén el- 
helyezkedő lokális változókban tárolt referenciák és a heap 
objektumaira vonatkozó hivatkozásokat tartalmazó CPU-re- 
giszterek is. A gyökérlistát a JIT (just-in-time) fordító és a 
CLR tartja karban, a GC pedig bármikor hozzáférhet annak 
tartalmához. 

Amikor a GC elindul, azt feltételezi, hogy a heap-en lévő 
összes objektum szemét, tehát egyetlen gyökér sem tartal- 
maz élő hivatkozást. Ezután a GC sorra végiglátogatja a gyö- 
kérkészlet elemeit, végigköveti az adott gyökérből kiinduló 
hivatkozási láncot, és gráfot épít az elérhető objektumokból. 
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Az ábrán látható 1., 4., 5., 8. objektumokra közvetlen gyö- 
kérhivatkozás található, így azok felkerülnek a gráfra. Az 5. 
objektum hozzáadásakor a GC megtalálja az objektumban 
lévő hivatkozást a 9. objektumra, és így azt is a gráf megfe- 
lelő ágához csatolja. Ez azért lehetséges, mert a CLR a 
heap-en lévő minden objektumról , tudja" annak valódi típu- 
sát, a referenciához tartozó metaadatokból pedig megha- 
tározható, hogy az objektum mely tagjai hivatkoznak más 
objektumokra. A GC az összes elérhető objektumot rekurzi- 
van végiglátogatja. 

Ha a GC olyan objektumot talál, amit már hozzáadott a 
gráfhoz, az adott ágon megállítja a keresést, mivel ebben 
az esetben az onnan elérhető objektumoknak is már a grá- 
fon kell lenniük. Ez egyrészt jelentősen csökkentheti a kere- 
sésre fordított időt, másrészt így elkerülhetők a végtelen 
ciklusok, amelyeket a körkörös hivatkozások okozhatnak. 
Miután a GC a keresést az összes gyökérből kiindulva elvé- 
gezte, a gráfnak tartalmaznia kell minden olyan objektu- 
mot, amelyek valamilyen módon elérhetőek az alkalmazás- 
ból. A gráfon nem szereplő objektumok az alkalmazás szá- 
mára már nem használhatók, tehát a GC fel fogja szabadi- 
tani az általuk elfoglalt memóriaterületet. A memória felsza- 
badítása a legmagasabb címen kezdődik, és az alapcím 
felé halad. Az eltávolított objektumok helyén ezután lyukak 
maradnak a címtérben, ezért a megmaradt objektumokat a 
GC az alapcím közelébe mozgatja, hogy az általuk elfoglalt 
címtér folytonos legyen. Az objektumok mozgatásával ter- 
mészetesen együtt jár a hivatkozások módosítása is. A GC 
feladata a gyökérkészletben és az objektumokban lévő re- 
ferenciák aktualizálása is. 
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A heap a GC futása után 


Ezután a GC beállítja a szabad terület kezdetét jelző muta- 
tót, és folytatódhat az a felfüggesztett művelet (új objektum 
létrehozása), ami a begyűjtést kiváltotta. 

Látható, hogy a referencia nélküli objektumok megkeresé- 
se és eltávolítása idő- és erőforrás-igényes művelet, ezt az 
árat kell fizetnünk a gyors és egyszerű memóriafoglalásért 
és a memóriakezeléssel kapcsolatos hibalehetőségek ki- 
küszöböléséért. A begyűjtés azonban viszonylag ritkán kö- 
vetkezik be (csak akkor, ha a heap megtelt), és az objektu- 
mok generációkba sorolása (az objektumgenerációkról a 
második részben részletesen szólunk) is jelentősen csök- 
kenti az egyes begyűjtések időigényét. 


A Finalize metódusok 

A Finalize metódusok azt teszik lehetővé, hogy az objektu- 
mok megfelelően lezárják az általuk használt nem mene- 
dzselt erőforrásokat, mielőtt a GC áldozatául esnének. Kis- 


sé leegyszerűsítve az eseményeket, azt mondhatjuk, hogy 
miután a GC memóriaszemétnek minősít egy adott objektu- 
mot, meghívja annak Finalize metódusát (ha létezik ilyen), 
mielőtt felszabadítaná az általa elfoglalt memóriát. A Finali- 
ze az Object osztály metódusa, felülírásának szintaktikája a 
következő (lenne): 


public class AlapObjektum ( 
public AlapObjektum() ( 
h 
protected override void Finalize() ( 
//nem menedzselt erőforrások lezárása 
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A Ct fordító azonban nem hajlandó ennek lefordítására, 
mert nem engedi a Finalize metódus felülírását (a VB.NET 
fordító igen). 

Amikor a fordító egy osztály konstruktorának kódját gene- 
rálja, automatikusan beilleszti az ősosztályok konstruktorait 
is. A C4-4 fordítók ugyanezt teszik a destruktorok esetében 
is. A Finalize metódusok esetében nem ez a helyzet, ha 
ilyen viselkedést szeretnénk, a metódus végén explicit mó- 
don meg kell hívnunk az ősosztály Finalize metódusát. A 
Ctt programnyelvben a C--4- destruktorokhoz hasonló szin- 
taktikával helyettesíthetjük a Finalize metódus felülírását és 
az ős Finalize metódus explicit meghívását: 


class AlapObjektum ( 
-AlapObjektum() ( 


, 


Nézzük meg a korábban említett és használt Szemet osz- 
tály ilyen szintaktikával megadott metódusából generált IL 
kódot: 






98 olxi 
class [mscorlib]System.Threading.Threaca 
instance int32 [mscorlib]System.Object: 
[mscorlib]System. Int32 

string [mscorlib]System.String: :Concat( 

















L.O01f: call 
L 0024: calluirt 
L-0029: box 

L 002e: call 


IL 0033: call Void [mscorlib]sSystem.Console: :WriteLir 


IL 0038: leave.s IL 0041 
) // end .try 
finally 
f 
IL 003a: Idarg.0 
IL 003b: call instance void AlapObjektum: :Finalize( ) 
IL.0040:  endfinally 


) // end handler 
IL 0041: ret 
) // end of method Szemet: :Finalize 


Az ősosztály Finalize metódusának meghí- 
vása 


A metódus az IL kódban már Finalize() néven szerepel, és 
láthatjuk, hogy a fordító a metódus végére beillesztette az 
AlapObjektum osztály Finalize metódusának meghívását is. 
A szintaktikai hasonlóság ellenére azonban a fenti kód nem 
,gazi" destruktor, nincsen arra lehetőség, hogy a kódból 
meghívjuk. Osztályaink megtervezésekor, ha csak lehet, 
kerüljük el a Finalize metódus használatát. Ennek okai a kö- 
vetkezők: 

m AFinalize metódussal rendelkező objektumok (és az 
általuk hivatkozott összes objektum) memóriaterüle- 
tének felszabadítása csak két lépésben (a GC két- 
szeri futásával) lehetséges (ennek okát a második 
részben részletesen meg fogjuk vizsgálni). 

m A Finalize metódussal rendelkező objektumok memó- 
riafoglalása hosszabb időt vesz igénybe. 

mu Nagyszámú objektum esetén a Finalize metódusok 
meghívása sok időt vehet igénybe. 

m Nem tudhatjuk, hogy mikor fog lefutni az objektum Fi- 
nalize metódusa, így az alkalmazás hosszú ideig fog- 
lalva tarthat olyan külső erőforrásokat (például adat- 
bázis-kapcsolat), amelyek mielőbbi felszabadítása 
fontos lenne. 

m Semmilyen módon nem befolyásolhatjuk a Finalize 
metódusok meghívásának sorrendjét, ami egymásra 
hivatkozó objektumok esetén véletlenszerűen jelent- 
kező futási hibákhoz vezethet. 


Ha mégis szükséges a Finalize metódus használata, bizto- 
sítanunk kell, hogy a kód a lehető leggyorsabban, minden 
felesleges várakozás (például szálak közötti szinkronizá- 
ció) nélkül végrehajtható legyen. A Finalize metódusok he- 
lyett a második részben bemutatott Dispose vagy Close 
metódusok használata javasolt. 


A következő részben tovább folytatjuk a Garbage Collector 
belső működésével való ismerkedést. Szó lesz majd az ob- 
jektumok , újraélesztéséről", a gyenge referenciákról (weak 
references) és az objektumok generációkba sorolásáról, 
amelynek segítségével a GC futása kevesebb erőforrást és 
időt igényel. Bemutatjuk továbbá a Dispose és Close metó- 
dusok helyes megtervezésének módját, valamint megvizs- 
gáljuk a Garbage Collector működésének valós idejű moni- 
torozására szolgáló eszközöket is. 
SZERÉNYI LÁSZLÓ 
szerenyi . kamet.bu 


adása ada Lél zi elt 


[1] http;//store.netacademia.net/mshu/OTHER/ 
b technet. code/ gc.zip 











Fejlesztésmenedzs- 
ment módszertanok 


SZEMPONTOK ÉS NÉZŐPONTOK 


Az informatikai cégek különbözőképpen reagálnak, 


ha fejlesztésmenedzsment módszertanokról kérdezzük 


őket. Egy részük azonnal rávágja az alkalmazott 


metodika nevét és fő jellemzőit, míg a másik véglet némi 


bizonytalanság után közli, hogy náluk ilyesmire nincs 


szükség, hiszen minderki érti a dolgát. 


ben vettem részt: ezek között volt olyan, amelyben 

egy 60-70 fős csapat egyik fogaskereke lehettem, 
máskor 3 fős fejlesztői gárda egyik tagja voltam, és az is elő- 
fordult, hogy a szakmai tervezés lett a feladatom. Így nyu- 
godt szívvel mondhatom, hogy elég sokféle szemszögből 
láttam már egy-egy szoftver fejlődését. 


E- pályafutásom során több informatikai projekt- 


Megközelítések 
Ha megkérdezzük az IT cégeket, milyen módszertant alkal- 
maznak munkájuk során, gyakorlatilag mindenki másképp 
válaszol. Nem mintha ilyen kifinomult lenne a vezetés min- 
denhol, egyszerűen arról van szó, hogy a megvalósításban 
emberek vesznek részt, akik különböző egyéniséggel, kü- 
lönböző tapasztalatokkal és tudással rendelkeznek, 
s mindezeket akarva-akaratlanul hozzák magukkal. Ráadá- 
sul a csapattagok közötti együttműködésre soha nem te- 
kinthetünk úgy, mint valamilyen gépies folyamatra, amely- 
ben gondolkodás nélkül követik a kiadott instrukciókat, ha- 
nem ahhoz mindenki hozzáteszi saját gondolatait, tudását, 
sőt, az emberek egymás közötti kapcsolata is meghatározó 
lehet. 
Mindezek kezelését gyakorlatilag minden vállalat másképp 
oldja meg, saját igényeihez, lehetőségeihez és korlátaihoz 
igazítva. Ezek a megközelítések azonban helyenként ha- 
sonlíthatnak egymásra, így véleményem szerint három nagy 
csoportba sorolhatók: 

1. a cégnek nincs kialakult koncepciója, 

2. a cég egy az egyben átvesz valamely nagy és közis- 

mert módszertant, és azt alkalmazza, 
3. a cég saját metodikát dolgoz ki informatikai projektjei- 
nek irányítására és lebonyolítására. 


Koncepció nélkül 

A koncepció nélküli cégek többnyire kicsi vagy újonnan ala- 
pított vállalkozások, bár bőven akad ellenpélda is. Sajnos 
régóta működő, egyre növekvő vállalatoknál is gyakran 
megfigyelhetjük, hogy nincs kialakult koncepciójuk, a fej- 
lesztési vezetőkre van bízva, mit és hogyan csinálnak. Ter- 





mészetesen ez egyfajta szabadságot biztosít, ami kreativi- 
tásra motiválhatja az embereket. 

Mindennek azonban rengeteg hátulütője is lehet: először is, 
ha nincsenek lerögzítve legalább az alapjai annak, hogy ho- 
gyan és milyen munkát várunk, az félreértésekhez vezethet. 
Ha valaki már évek óta nálunk dolgozik, felgyülemlett már 
annyi tapasztalata, hogy tudja, mi az, amit elvárunk tőle, és 
mi az, amit nem szeretünk látni. Ha azonban valakit újonnan 
vettünk fel, rengeteg konfliktus adódhat abból, ha ő hozza a 
saját tapasztalatait és elképzeléseit, és azok nem egyeznek 
a mieinkkel. Ráadásul ha kérdezi, mit és hogyan szeret- 
nénk, gyakran csak néhány ködös mondatban tudjuk azt el- 
mondani neki, ami meglehetősen kevés ahhoz, hogy megis 
értse, pontosan hogyan képzeljük el az együttműködést. 
Sőt az is előfordulhat, hogy különböző kollégák különböző 
szemszögből látják a folyamatokat, így elmondásaikból 
meglehetősen nehéz összerakni egy egésszé, pontosan mi 
is a globális elképzelés. 

A másik problémás kérdés ebben az esetben, ha valaki 
másik csapatba kerül a cégen belül. Ennek számos oka le- 
het, az átszervezéstől kezdve az előléptetésig, illetve a pro- 
jektszervezésű vállalatoknál mindez igen gyakori. Ha ugya- 
nis folyamatosan ugyanabban a környezetben, ugyanazzal 
a társasággal dolgozunk, akarva-akaratlanul is kialakul 
egyfajta munkamenet, a csapat idővel összeszokik. Ezeket 
a megszokásokat azonban nem könnyű levetkőzni, így ha 
az ember új környezetbe kerül, ösztönösen próbálja eddigi 
tapasztalatait felhasználni. Az átállás sokkal egyszerűbb, 
ha konkrétan rögzítve van, mi az, amire át kell szokni, amit 
meg kell tanulni és elsajátítani. Ha csak azt éreztetjük az 
emberekkel, hogy amit csinálnak, az úgy nem jó, viszont 
nem tudjuk elmondani, megmutatni, mi az, amit konkrétan 
elvárunk, könnyen ellenállásba és érdektelenségbe ütköz- 
hetünk. 

A koncepció nélküli vállalat természetesen lehet működőké- 
pes, azonban versenyképesnek maradnia nem egyszerű. A 
piaci helyzet ugyanis megkívánja, hogy a határidőket, költ- 
ségeket és egyéb korlátokat tartsuk. Ha nem alkalmazunk 
semmiféle koncepciót, már ezek becslése is nehéz, ném is 


beszélve a betartásukról. Előbb-utóbb érezni fogjuk a kísér- 
tést: valami hiányzik. . . 


Egy cégnél a következő helyzettel találkoztam: a kitűzött cél 
egy nyilvántartó rendszer kifejlesztése volt egy olyan plat- 
formon, amelyen korábban nem dolgoztak. A megrendelő a 
cégvezetés volt, bízva abban, hogy az elkészülő rendszer- 
re sikerül majd vevőket találni. A fejlesztéshez vettek fel új 
embereket is. A szoftverről azonban csak egy ködös elkép- 
zelés állt rendelkezésre, és a technológia is új volt, így sen- 
ki nem tudta megbecsülni, mennyi idő alatt és mekkora költ- 
ségvetéssel készülhet el. A specifikációk folyton változtak, 
hiszen nem szorított a határidő. Egy idő után már mindenki 
kezdett belefásulni, hiszen mint egy rágógumi, nyúlt a do- 
log, ám kézzelfogható eredmény nem volt. 

A rendszer mind a mai napig nem készült el. Fejlődése so- 
rán szervezeti és technológiai átalakításokat egyaránt 
megélt, azonban a folyamat vége nem látszik. Érthető mó- 
don a vezetőség türelme egyre fogy, a fejlesztők pedig — bár 
szeretik munkájukat — egyre kevésbé motiváltak. 

Ha nincsenek határidők, nehéz tar- 

tani azokat. Ha nincsenek költség- Em 

korlátok, nagyon könnyen abba a 
hibába esünk, hogy minden felme- 
rülő ötletet igyekszünk megvalósí- 
tani. Így azonban a rendszer még 
később lesz kész - és a kör bezá- 
rult. Ha viszont nem tudjuk, mikor 
leszünk készen, mekkora befekte- 
téssel, és mit fog tudni pontosan 
a rendszer, eladni sem lesz egy- 
szerű azt. 

Sokkal célszerűbb azt mondani: 
rendben, az első verzió ezt és ezt a funkciócsoportot tudja 
majd, a menet közben felmerülő ötletek később kerülnek 
megvalósításra. Ezzel elkerülhetjük a ,rétestészta-effek- 
tust", és az apró részekre bontott, konkrét célokat kitűző 
rendszer megvalósítása is egyszerűbb, átláthatóbb, ezáltal 
az emberek motivációja is növelhető. Ha látják, mit kell elér- 
ni, és sikerélmények tarkítják az utat, sokkal lelkesebben és 
odaadóbban végzik majd munkájukat. 

Ehhez azonban fel kell ismerni a változás szükségességét, 
és határozott lépéseket kell tennünk azok megvalósításáért. 


Jól bevált módszertan alkalmazása 
Ha eljutottunk abba a fázisba, hogy látjuk: reformokra van 
szükség ahhoz, hogy vállalatunk hatékonyan és eredmé- 
nyesen működhessen tovább, az elsőként kínálkozó megol- 
dás: vezessünk be olyan ajánlásokat, amelyek máshol már 
bizonyítottak. 

Az ötlet alapvetően nem rossz, azonban van néhány dolog, 
amire érdemes odafigyelni ebben az esetben is. Először is: 
mindenképp figyelembe kell vennünk, hogy cégünk, projek- 
tünk és embereink mind-mind saját egyéniséggel rendel- 
keznek. Mint ahogy nincs két egyforma ember, ugyanúgy 
különböznek a vállalatok, a csapatok és a folyamatok is. 
Ráadásul nem szabad megfeledkeznünk a különféle külső 
hatásoktól, amelyek előre soha nem kiszámíthatók. 

Így ha arra a döntésre jutunk, hogy mások által kidolgozott 
módszertant kívánunk bevezetni, vegyük figyelembe azon 
sajátosságokat, amelyek eltérőek lehetnek. 


A koncepció nélküli 
vállalat természetesen 
lehet működőképes, 
azonban versenyképesnek 


maradnia nem egyszerű. 


Először is, nem biztos, hogy az adott módszertan vala- 
mennyi aspektusát alkalmaznunk kell. Ha a projekt mérete, 
keretei vagy a csapat összetétele úgy kívánja, bátran hagy- 
juk el azon részleteket, amelyeket feleslegesnek ítélünk. 
Például a metodikák nagy része jelentős dokumentáció- 
igénnyel rendelkezik, ezek többsége azonban szükségte- 
lennek bizonyulhat rövid terjedelmű, kis projektek esetén. 
Természetesen nem az a cél, hogy semmit ne dokumentál- 
junk! Sőt! Ne arra törekedjünk, hogy minél kevesebb admi- 
nisztrációval járjon a munkánk, hanem a minél teljesebb 
megoldásra, amely azonban mentes a felesleges szócsép- 
léstől. 

Másik kritikus tényező a különböző megbeszélések gyakori- 
sága és rendje. A projektvezetők gyakran abba a hibába 
esnek, hogy túl gyakran hívják össze az embereket, akik így 
a kommunikációs lehetőség helyett munkájuk akadályozta- 
tását érzik elsősorban. Fokozottan jelentkezik ez, ha nem- 
csak azokat hívjuk meg, akik feltétlenül szükségesek az 
adott témával, döntéssel kapcsolatban, hanem sok olyan 
személyt is, akinek a munkája meglehetősen távol áll a terü- 
lettől. Alapvetően arra kell figyelni, 
hogy a döntések előkészítésekor és 
meghozatalakor is csak azok legye- 
nek jelen, akik kompetensek a té- 
mában. Például egy részletekbe 
menő technológiai megbeszélésre 
ugyanúgy felesleges odarendelni 
az üzleti oldalt, mint ahogy a fejlesz- 
tőket sem célszerű egy felső szintű 
üzleti megbeszélésre invitálni. 

A megrendelő és a fejlesztők között 
mindig legyen egy olyan interfész- 
ember (vagy csoport), akinek 
feladata az egyeztetés, közvetítés. Ez a személy lehetőleg 
értsen a feladat szakmai és üzleti részéhez egyaránt, hiszen 
munkáját csak így végezheti hatékonyan. 

A konkrét, külső módszertanokkal kapcsolatban két céget 
mutatnék be: mindkét helyen ugyanazt a módszertant al- 
kalmazzák. Az első vállalat mereven ragaszkodik az előírá- 
sokhoz, mindenben a kiválasztott metodika lépéseit követi. 
Az így keletkező többletmunka azonban gyakran akkora 
terhelést jelent, hogy az embereknek alig jut idejük a mun- 
ka érdemi részére. Így egyrészt a határidők mindig csúsz- 
nak, a költségkeret folyamatos bővítésre szorul, ráadásul 
az emberek nemcsak a feladatukat, hanem a módszertan 
által megkövetelt lépéseket sem tudják precízen végezni. 
A másik vállalatnál nem ennyire merevek: ők úgy gondolják, 
ragaszkodnak az adott módszertanhoz, viszont ahol szük- 
ségesnek találják, testreszabják azt. Így egyrészt van egy 
konkrét, kialakult, ledokumentált rendszer, amely alapján 
munkájukat végzik, másrészt ezt kellően rugalmasan keze- 
lik ahhoz, hogy ne akadályozza, hanem segítse őket. A cég 
ily módon képes a határidők betartására, a költségek 
kézben tartására, és a megvalósítandó funkciók megfelelő 
kezelésére. Véleményem szerint azonban ennek a megol- 
dásnak is lehetnek buktatói. Egy előre , gyártott", kész mód- 
szertan mindig úgy születik, hogy az adott cég ledokumen- 
tálja saját folyamatait, majd ebből különböző általánosítások 
alapján egy olyan metodikát publikál, amely kellően átfogó 
és általános ahhoz, hogy mindenkinek nyújthasson prakti- 
kus ötleteket. Ugyanakkor ennek az összefoglaló, mindenre 
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kiterjedő jellegnek köszönhetően helyenként túl sokat is kö- 
vetelhet, és túl keveset is adhat, a konkrét projekt természe- 
tétől függően. Ha pedig mindezt testre akarjuk szabni, fel- 
merül a kérdés: vállalati vagy projekt szinten kívánjuk min- 
dezt? Ha felső, vállalati egységes kialakításban gondolko- 
dunk, az a probléma, hogy nemcsak a cégek, hanem a pro- 
jektek is különbözőek, így elképzelhető, hogy ugyanazon 
szervezeten belül más vezetése alá tartozó, más projektek 
más módszertant igényelnek. Ekkor pedig nem sokat értünk 
a testreszabással. 

Nyitott maradt a kérdés: mi a helyzet azzal a szituációval, 
amikor ragaszkodunk valamely módszertanhoz, azonban 
azt minden alkalommal, minden új projektre testreszabjuk. 
A vállalatok többségénél egyszerre több fejlesztés is 
folyik. Ha ezek mindegyikénél egyedileg alakítjuk ki az al- 
kalmazott stratégiát, egy idő után követhetetlenné válhat, 
hol hogyan dolgozunk, és ki milyen szempontok alapján 
alakítja ki a projektkörnyezetet. Így a cégen belül is kaoti- 
kus, áttekinthetetlen lehet a helyzet, és az emberek átmoz- 
gatása egyik projektből a másikba igencsak nehézkessé 
válhat. 

Természetesen mindez megfelelő adminisztrációval, több- 
letmunkával elkerülhető, azonban adódik egy harmadik, 
ígéretes, ám nem egyszerű megoldás is. 


Saját módszertan kidolgozása 

A nagyok" módszertanaiból rengeteget lehet tanulni, azon- 
ban mint láthattuk, alkalmazásuk nem mindig egyszerű. A 
levont tanulságok, megszerzett ismeretek jól alkalmazhatók 
egy flexibilis környezetben, ahol nem a módszertanhoz való 
merev ragaszkodás a cél, hanem a hatékony, eredményes 
munka. 

Ha saját, testreszabott metodikát szeretnénk kidolgozni, ér- 
demes odafigyelni néhány problémára: az első és legfonto- 
sabb kritérium, hogy ne essünk ugyanabba a hibába, mint 
a másoktól átvett szabályozások alapján, vagyis új mód- 
szertanunk ne legyen túl merev, könnyedén el lehessen 
hagyni egyes részeit, vagy szükség szerint kiegészíthessük 
újabb komponensekkel. Ez azonban ismét azt a kérdést ve- 
ti fel, hogy hogyan kerülhetjük el a követhetetlen, mindig 
másképp levezényelt projekteket, hiszen a módosítás sza- 
badsága rengeteg félreértéshez vezethet. 

A megoldást az jelentheti, ha nemcsak a konkrét, vállalati 
szintű módszertant határozzuk meg, hanem arra is adunk 
ajánlást, hogy ezt hogyan, milyen irányban lehet módosíta- 
ni. Ha azt is ledokumentáljuk, melyik projekttípushoz mit ja- 
vaslunk, a szabadságból semmit nem veszünk el, azonban 
cégünket mégis az egységesítés felé tereljük, és ezáltal 
mind a minőségbiztosítási, mind a szervezeti kritériumoknak 
megfelelhetünk. 


Hogyan álljunk tehát neki a munkának? Előre leszögezem: a 
feladat nem egyszerű. 

Először is fel kell mérnünk, mik azok a dolgok, amelyek je- 
lenleg jól működnek. Ha a cégünk még életben van, akkor 
jó eséllyel találunk ilyeneket, bármilyen elkeserítőnek látjuk 
is a helyzetet. Járjunk annak is a végére, hogy hogyan, mi- 
től működnek ezek a dolgok, s vegyünk számításba min- 
dent: lehet, hogy egy-egy rátermett ember a kulcstényező. 
Lehet, hogy többé-kevésbé tudatosan módszeresen dol- 
goznak az emberek, és persze az is előfordulhat, hogy a si- 


ker csupán a véletlen műve. Ez az esély azonban hosszú tá- 
von egyre inkább a nullához közelít. . . 

Természetesen mindezek felmérése során teljesen objektív- 
nek kell lennünk, hiszen e nélkül szinte az egész erőfeszítés 
felesleges. Hasznos lehet külső szakértő bevonása is, aki 
hozzáértő módon, független szempontból vizsgálja át cé- 
günk működését. 

Ha már úgy érezzük, hogy mindent tudunk a vállalatról, illet- 
ve csoportjainkról, elkezdhetjük összeszedni azokat a dol- 
gokat, amelyek már most is működnek, és egybevágnak 
céljainkkal, illetve azokat is,a melyek szöges ellentétben áll- 
nak azokkal. 

Tegyük fel például, hogy ügyfeleink elégedettségén szeret- 
nénk javítani, ám korábban egyetlen projektben sem vontuk 
be őket a tervezésbe. A probléma leírása után megszakítot- 
tuk velük a kapcsolatot, és legközelebb az átadásnál talál- 
koztunk. Érezhető, hogy a megoldás első lépése rögtön az, 
hogy ezen a hozzáálláson változtassunk. Képzeljük el, mit 
éreznénk, ha a házunkat úgy építenék fel, hogy mi (jó eset- 
ben) látjuk a terveket, majd legközelebb a kulcsátadásra 
engednek oda bennünket. Ugyanígy a megrendelőket, ügy- 
feleket sem csak az előkészítéskor, hanem a projekt teljes 
életciklusa során be kell vonni a munkába, hogy az állandó 
kapcsolat eredményeként szoros és hatékony együttműkö- 
dés jöhessen létre. 

Ha tehát már látjuk, mit csinálunk jelenleg jól, és mi az, amin 
változtatni kell, összeáll egy átfogó kép, amelyet összevet- 
hetünk különböző, korábban megismert módszertanokkal.: 
melyik az, amely leginkább megfelel a jelenlegi állapotnak, 
melyik vezet leggyorsabban céljainkhoz? Melyik az, amely- 
nek bevezetése a legkevesebb , fájdalommal" járna? 

És itt jön a lényeg: ebben a lépésben nem szükséges egyet- 
len módszertan mellett elkötelezni magunkat. Sőt! Úgy gon- 
dolom, ha különböző forrásokból összegyűjtjük a lehetősé- 
geket, és azokból egy saját, testreszabott, jól paraméterez- 
hető metodikát dolgozunk ki, az lehet a leghatékonyabb. Így 
akár arra is tekintettel lehetünk, hogy hogyan tudjuk fokoza- 
tosan, lépésenként , forradalmasítani" munkánkat, melyek 
azok a fázisok, amelyeket akár azonnal meg tudunk valósí- 
tani, és melyek azok, amelyek alaposabb előkészítést igé- 
nyelnek. 


Az újítások bevezetése 
Természetesen nem elég, ha mindez a fejünkben összeáll, 
vagy papíron leírjuk és közzétesszük. Cégünknél be is kell 
vezetni az újításokat, hogy azok érjenek valamit. Egyik nap- 
ról a másikra azonban nem lehet megváltani a vállalatot. 
Hiába vagyunk jó vezetők, ha minden előzmény nélkül kiál- 
lunk dolgozóink elé, és azt mondjuk: mától ezt és ezt a mód- 
szertant fogjuk alkalmazni — semmit nem érünk el, csupán 
kemény ellenállásba ütközünk. Fokozatosan, lépésről lé- 
pésre sokkal messzebbre juthatunk. Ráadásul ha a beveze- 
tendő módszertanunkat jól dolgoztuk ki, és bevezetését jól 
készítettük elő (belső marketing, a dolgozók folyamatos tá- 
jékoztatása, stb.), senki nem fogja erőltetettnek vagy feles- 
legesnek érezni azt. 
Így pedig határozottan könnyebb, kellemesebb és kényel- 
mesebb, sőt hatékonyabb lesz a munka. Kell ennél több? 
MOLNÁR ÁGNES 
rendszertervező 
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ÜUzletiintelligencia- 


szoftverek 


MS SOL 2000 REPORTING SERVICES II. RÉSZ 


Az üzleti intelligencia minden vállalat életében nélkülözhe- 


tetlen, segítségével megalapozott döntéseket 


hozhatunk, amelyek sikeressé tesznek minket a piacon. 





Az üzleti intelligencia nem feltétlenül igényel egy teljes 


OLAP-ot vagy adatbányászatot, mint amilyenek az SOL. 


Server Analysi 


Services-re épülő megoldások, 


de minden üzletiintelligencia-megoldásnak van egy közös 


eleme: a jelentések (report-ok). 


Jelentéskészítés VS.NET Report 
Designer-rel 

A korábbi részben bemutatott kimutatáskészítés életcik- 
lus-diagramja alapján el fogunk készíteni egy jelentést, 
majd publikáljuk a Report Server-be. Először is el kell ké- 
szítenünk magát a kimutatást. Erre két lehetőségünk van. 
A Report Definition Language (RDL) ismeretében saját 
magunk összerakhatjuk azt az XML fájlt, ami teljes egé- 
szében leírja a kimutatás vizuális komponenseit, vezérlőit, 
a paramétereit, az adatforrást, a kimeneti formátumot és 
még sok mást. A Reporting Services Books Online-ban 
(RSBOL) megtalálhatóak az adott XML állományban hasz- 
nálható elemek [1], segítségünkre lehet még egy XML 
diagram is [2], amely bemutatja a főbb elemek sémabeli 
elhelyezkedését, valamint az elkészült RDL állományunk 
ellenőrzésére felhasználható egy XSD dokumentum [3]. Ez 
a módszer jó lehet, ha egy olyan alkalmazást kell készíte- 
nünk, amelynek a feladata magának a kimutatásnak az 
összeállítása dinamikusan, gyakran az ügyfél gépén. 
Amennyiben előre elkészített jelentéseket akarunk gyor- 
san elkészíteni, segítségünkre siet a Visual Studio 2003 
(VS.NET) egy új projekttípussal. 


A kimutatás varázsló 

Indítsuk el a VS-t, és válasszuk ki a Business Intelligence 
Projects-ek közül a Report Project Wizard-ot, majd nevez- 
zük el a projectet például Sales Reports-nak (1. ábra). 


Majd a varázsló üdvözlő képernyőjét átlépve állítsunk be 
egy adatforrást a Reporting Services-zel együtt települt 
AdventureWorks2000 példa adatbázisára (2. ábra). 


Ezt az adatbázis kapcsolatot megosztottá is tudnánk tenni, 
ezáltal a kapcsolat nem a kimutatásban tárolódna el, hanem 
a projektünkben, ami egy különálló állományt alkotna a je- 
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New Project 


(A Business Inteligence Projects 
CI Visual Basic Projects 
C visual Cé Projects 
CI Visual 38 Projects 
87 CI Visual C-t Projects 
XI Setup and Deployment Projects 


f€reate a newreport project using Report Wizard. 





Name: [ddesReports 
ca s] — Erowse... 


Project wil be created at C:(Sales Reports. 43 
— ree ] bo 1 eme ] 0 we ] 


1. ábra Új projekt készítése 


Location: 





LTE 
Select the Data Source 


Select a data source from which to obtain data for this report or create a new 
data source. 








G Newdata source] 
Name: 
fadventureworks2000 
Iype: 
Microsoft SOL Server hd 


Connection string: 


data sourcezílocal);initial catalogzAdventureworks2000 Edit... 


- 2. ábra Adatforrás kiválasztása 


lentés publikálásakor. Akkor van igazán előnye ennek, ha a 
kimutatásprojektünk sok-sok kimutatásból áll, de ugyan- 
azon adatforrásból táplálkozik, ilyenkor központilag tudjuk a 
kapcsolatot megváltoztatni. A következő lapon a lekérde- 
zést tervezhetjük meg, amelyhez jár az Access-ben, az 
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SOL Server Enterprise Manager-ben már jól megszokott 
Ouery Builder. Adjuk meg a lejjebb látható lekérdezést, 


SELECT st..I[Name] AS Region, pc..I[Name] AS 
Category, 
psc..IName] AS SubCategory, 
SUM(p.ListPrice t sod.OrderOüty) AS Sales, 
SUM(p.StandardCost t" sod.OrderOdty) AS Cost 
FROM SalesOrderHeader soh 
INNER JOIN SalesOrderDetail sod 
ON soh.SalesOrderID - sod.SalesOrderID 
INNER JOIN Product p 
ON sod.ProductID - p.ProductID 
INNER JOIN ProductSubCategory psc 
ON p.ProductSubCategoryID - 
psc.ProductSubCategoryID 
INNER JOIN ProductCategory pc 
ON pc.ProductCategoryID - 
psc.ProductCategoryID 
INNER JOIN SalesPerson sp 
ON sp.SalesPersonID - soh.SalesPersonID 
INNER JOIN SalesTerritory st 
ON sp.TerritoryID - st.TerritoryID 
INNER JOIN Customer c 
ON soh.CustomerID - c.CustomerID 
WHERE st. [Group] - "North America" AND 
c.CustomerType — "S" 
GROUP BY st.[Name)], pc.[Name)], psc. [Name] 


amely leválogatja az AdventureWorks2000 példa adatbázis- 
ból a dél-amerikai csoporthoz tartozó értékesítési területek 
kiadásait, bevételeit területenkénti, kategóriánkénti, alkate- 
góriánkénti bontásban. A Next gomb után válasszuk ki a táb- 
lázatos (tabular) kimutatástípust. Az ezt követő táblázatterve- 
ző lapon pedig állítsuk be a kimutatás csoportosítását. 





E Report Wizard 
Design the Table 


Choose how to group the data in the table. B 
valable fields: Displayed fields: 
Page Region 


Group: Category 
ai 
sú 
Detalsz SubCategory 
Sales 


3. ábra A táblázat megtervezése 





A régiók laponként legyenek csoportosítva, ezen belül min- 
den lapon legyen kategóriánként csoportosítva, a csoport 
részletezésében pedig az alkategóriánkénti eladások sze- 
repeljenek (3. ábra). A további lapon válasszuk ki a táblá- 
zatelrendezésekből a lépcsőzetes (steppea) elrendezést a 
részösszegek megjelenítésével (include subtotals). Majd 
az újabb lapon beállíthatjuk a táblázatunk stílusát, hason- 
lóan egy Excel-táblázathoz, csak lényegesen kevesebb 
előre elkészített stílussal. Legyen például Corporate a stílu- 
sa. Az utolsó előtti lapon beállíthatjuk a majdani Report Ser- 
ver elérési útvonalát és az azon belüli telepítési könyvtárat. 
A végső oldalon pedig elnevezhetjük a kimutatásunkat, le- 
gyen például Sales by Region. A Finish gombra kattintva el 
is készül a kimutatásunk, amelyet design módban meg is 


tekinthetünk a Layout fül alatt. Ha átváltunk a Preview fülre, 
egy röpke fordítás után meg is jelenik a kimutatás futásidő- 
ben, láthatóvá válik a 6 oldalon a 6 különböző régió. Ez a 
mód csak egy lokálisan futtatott mód, nem tárolódik ekkor 
még a jelentés a Report Server-ben, viszont alkalmas arra, 
hogy a jelentésünk működését teszteljük. Ugyanezen a 
designer-lapon található a Data fül, ahol a varázslóban már 
megjelent Ouery Builder-t találjuk meg, lehetőséget adva a 
kimutatás alapjául szolgáló lekérdezés módosítására. Ha 
elkészültünk, nincs más hátra, mint publikálni a jelentés- 
projektünket a Report Server-be, amelyhez a VS.NET támo- 
gatást ad. A Solution Explorer-ben a projekt tulajdonságai- 
ban módosítható a Report Server elérése (TargetServer 
URL), illetve a telepítési könyvtár (TargetFolder), amennyi- 
ben a varázslóban elrontottuk. Majd a Build 2 Deploy So- 
lution menüponttal publikálhatjuk az elkészült kimutatásun- 
kat, így elérhetővé válik a hálózat minden egyes kliense 
számára webböngésző használatával a következő 


http: //localhost/Reports/Pages/Folder. aspx 


URL-ről elindulva. Mivel a projektünk neve Sales Reports 
volt, ezért a végleges útvonal, ahonnan elérhetjük: 


http: / /1localhost/Reports/Pages/Report . aspx? 
4 ItemPath-/Sales Reports/Sales by Region 


Az elkészült kimutatás módosítása 
Adjunk egy új oszlopot a már meglévő táblázatunkhoz. 
Gondolom, mindenkinek feltűnt, hogy a SELECT listában 
szereplő Cost alias nevű oszlopot nem használtuk fel. Kat- 
tintsunk a táblázatunk tetszőleges cellájára, majd a szer- 
kesztési módba került táblázaton a Sales oszlop fejlécre 
jobb egérrel kattintva válasszuk az Insert Column to the 
Right menüt. Ekkor kiegészül a 3 oszlop egy újabb negye- 
dikkel. Ezután a bal oldali eszköztárban lévő Fields ablak- 
ból húzzuk rá a negyedik oszlop legalsó cellájába (Detail/) 
a Cost mezőt. Látható, hogy az oszlop fejléce felveszi a 
mező nevét. Majd ugyanezt a műveletet ismételjük meg, de 
most a középső üres Cost cellába dobjuk bele a Fields ab- 
lakból a Cost mezőt. 







-Fields!Region. Value 






Category Sub 
zFieldsiCategor 


um] 2 7 








4. ábra Új oszlop hozzáadása 


Mivel ez egy aggregált oszlop, a Designer automatikusan 
kiegészíti a Sum() függvénnyel. Így lesz az értéket képvise- 
lő kifejezés: -—Sum(Fields!Cost. Value). Az egyenlőségjel az 
Excel-ből már ismerős lehet, az oszlopra pedig a Fields! je- 
löléssel hivatkozhatunk. Adjunk a táblázatunkhoz egy szá- 
mított oszlopot is, amelyben megjelenítjük a bevétel és a 
kiadás közötti árrést. Ehhez a Fields ablakban jobb egérrel 
válasszuk az Add menüt. Nevezzük el például Margin-nak 
(árrés) az oszlopot, és kiválasztva a Calculated field-et ad- 
juk meg a kifejezést (segít az fx gomb). 


5 kddiNew Field 


C Database field: 


————,r,m,m,m,m,—— 


(s Calculated field: 


[d gl 
Cancel I Help I 





5. ábra Számított oszlop hozzáadása 

















§ Constants 
7 Globals 

4 Parameters 

— Fields (AdventureWorks2000) 
Region 

Category 

SubCategory 

Sales 

Hi 
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Irsert 22 





Append 22 


91 Datasets 


6. ábra Általános kifejezés szerkesztő 
ablak 


Majd az előző Cost oszlophoz hasonlóan eljárva egészít- 
sük ki egy ötödik oszloppal a táblázatunkat, és a két üres 
cellára húzzuk rá a számolt Margin oszlopunkat. Ezeket a 
pénznemeket illik megformázni, hogy az aktuális pénznem- 
ben íródjanak ki az értékek. Egyszerre több cellát is kijelöl- 
ve (a Shift nyomva tartása mellett), majd az F4-gyel megje- 
lenítve a tulajdonság ablakot a Format-hoz adjunk meg egy 
nagy C-t (Currency), a Language-hez pedig a Hungarian-t. 
A másik módszer, hogy egyenként jobb egérrel kiválasztjuk 
a tulajdonság lapot, 


Ida TT Ja 


Name: 
textbox7 


Value: 
[/sumfFieldstsales Value) 7 2 


"Document map label: 
Je] 





(7 tide duplcates 


Containing group or dataset: e 


EI 





Textbox height: 
[7 Canincrease to accommodate contents 
IT Candecrease to accommodate contents 
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7. ábra A táblázat egy szövegmezőjének 
formázása 


illetve az Advanced gombra kattintva a Format fülön is sok 
egyéb beállításra nyílik lehetőség. Ha rákattintunk a táblá- 
zat bármelyik cellájára, úgynevezett sor- és oszlopkiválasz- 
tók jelennek meg a sor elején, illetve az oszlopok tetején. A 
Formatting eszköztár segítségével színezhetjük, formáz- 
hatjuk az egyes sorokat, oszlopokat, vagy akár cellákat is. 


Például a kategóriánkénti összesítő sor hátterét (a Detai/fe- 
letti sor), színezzük ki szürkére (LightGray). 


Paraméterezés 

Beszéltünk már róla, hogy a Reporting Services másik 
nagy előnye, hogy a kimutatások interaktivitása a jelentés- 
fájlokban lévő paraméterezési lehetőséggel van biztosítva. 
Azaz a jelentés együtt él, egységbe van zárva a jelentést 
befolyásoló paraméterekkel. Így a felhasználónak, amennyi- 
ben egy paraméterezett lekérdezést akar elindítani, előbb 
be kell állítania a szükséges paraméter értékeit (a lekérde- 
zési dátum intervallumai, régiószűrések stb. értékei). Egy 
valós eset, hogy a példánkban használt adatbázisból az 
egyes területek értékesítési menedzserei más és más ki- 
mutatást szeretnének kinyerni, pontosabban őket csak a 
saját eladási adataik érdeklik majd. Azaz a fenti SELECT ki- 
fejezésbe fixen beépített (Group - North America ) szűrést 
ki kell cserélni egy kívülről érkező és beállított paraméterre. 
Ehhez a designer-ben a Data nézetben meg kell keresni a 
lekérdezésünket leíró rácsban az — North America" kifeje- 
zést, ezt a Criteria oszlopban találjuk, és le kell cserélni az 
z OTerritory kifejezésre. 





ma GTerítory 
CustomerType c Where. a§ 


8. ábra Paraméter megadása a lekérdezésben 


A Report Designer automatikusan észleli a paraméterün- 
ket, és felveszi a paraméterkollekcióba. Ha megnézzük a 
Preview nézetet, azt látjuk, hogy megjelenik egy Territory 
paramétert bekérő szövegdoboz, de nekünk kell kézzel 
beírni az értéket, méghozzá pontosan, különben a lekérde- 
zés nem eredményez egy sort sem. 


LJCAZIEKIKETETE 2 Preview 
Territory 
oli a kh of 6 .n 1009 2] 





s 9 alá la H- 


9. ábra A paraméter első megjelenése a ki- 
mutatásban 


Ehelyett szebb lenne, ha feltöltődne egy legördülő lista a 
lehetséges értékekkel. Mi sem egyszerűbb! Egy kimutatás- 
állományban több lekérdezés is szerepelhet, így elkészít- 
hetünk egy olyat, ami visszaadja az összes területet az 
adatbázisból. A Data nézetben adjunk a meglévő DataSet- 
ünk mellé egy újabbat. 


"I Layout [ Fé. Preview 


ödventureworks2000 r] s. HÉ 
Adventureworks2000 


mA Data 


Dataset: 








E ATTE 


- 10. ábra Több DataSet létrehozása egy je- 
lentésben § 


Adjuk meg a DataSet nevét (pl. Territories), a DataSource 
még mindig a kezdetben beállított AdventureWorks2000, a 
Commana type pedig Text, majd írjuk be a következő lekér- 
dezést, amelyet persze a Ouery Builder segítségével is 
össze lehetett volna rakni. 


BoDa4a OS 
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SELECT [Group] FROM 
SalesTerritory 
GROUP BY [Group] 


A végeredményt ki is próbálhatjuk a felkiáltójel (!) megnyo- 
másával. Amit kapunk: Europe, North America és Pacific. 
Ezek után a Lajout nézetben nyissuk meg a Report 2 Re- 
port Parameters menüt. Majd a korábban létrehozott Terri- 
tory paraméterhez rendeljük hozzá a most elkészített Data- 
Set-et (Territories). A Value field kerül behelyettesítésre a le- 
kérdezésbe, míg a Label field lesz a megjelenített mező a 
listában. Ne engedjük meg a NULL értéket, és a blank üres 
sztring értéket se. Állítsunk be alapértelmezett (Non 
gueried) értéknek Europe-ot.. 


Wa Data [8/ Lavout JET 
































Parameteri Properties: 
anió . time: Eromot: 
e ferzary erte 
. 
—] Datatypes 
EZ] T Aonrákvkse 
IT Alom blank valva 
Avadable valuesi 
Dutaset: 
§ 
msjsást Terzones J 
G from gvery Vake field: 
Gap :] 
Label field: 
dos 2 
Defaut valvesz 
GE tarat 
a ol a. Ess mese JENBÓ 
€ From azery 
szőtt 7] 
€ hepe 
Bemove 


12. ábra DataSet hozzárendelése a para- 
méterhez 


További interaktív jelentések 

A fentiekben vázolt paraméteres kimutatások az interaktív 
jelentések egyik csoportját alkotják. Egy másik csoportot 
alkotnak az úgynevezett drill-down, valamint a kimutatás 
egyes részeinek elrejtését használó jelentések. Ha azt sze- 
retnénk elérni, hogy például az egyes kategóriák alatti 
részletek rejtve legyenek mindaddig, amíg le nem nyitja a 
felhasználó egy-egy kategória esetén, akkor nem kell mást 
tenni, mint a Layout nézetben a táblázatban kijelölni a 


beje ja 


General ] Fiters. [VEbüty7] Data output ] 








Initial visibility: 
C Visible 
6 Hidden 
C Expression: 


-£] 


[7 Visibiity can be toggled by another report item 


Report item: 
jcategory . 


- 13. ábra A láthatóság beállítása az , Edit 


Group"-on keresztül 


. DD 


legalsó szintű Detai/ sort. Majd F4-gyel megnyitni a tulaj- 
donság ablakot, és a Visibilíty csoportban beállítani a 
Hidden tulajdonságot True-ra (alapértelmezetten a csopor- 
tok össze lesznek csukva), valamint a Toggleltem tulajdon- 
ságot arra az értékre, amely az adott kibontandó táblázat 
cellát képviseli, jelen esetben a Category oszlop, itt lesznek 
majd láthatóak a --/- jelek. Ugyanezt megtehetjük úgy is, 
hogy a kijelölt soron jobb egérrel az Edit Group menüt vá- 
lasztjuk ki, majd a Visibility fülnél állítjuk be az értékeket 
(13. ábra). 


CEJENET 3 reven 


Territory Pacific . 
CÍRIK 4 Beta : 1] 9 B]lé(G B- [o08 7] 
Sales by Region 
[/docstralia 
Cate: Sub Cate Sales Cost 
E Accessory 3103547 Ft 17069 51 Ft 13965.96 Ft 
E Bike 2105 46045 Ft 1.553 04073 Ft 547 41972 Ft 
Mountain Bike 195443.91 Ft 144 62849 Ft 50 81542 Ft 
J Road Bike 4886,70 Ft 361616 Ft 1 270,54 Ft 
Tounng Bike 1905 12984 Ft 1.409 796,08 Ft 495 333,76 Ft 


14. ábra A drill-down kimutatás 


Egy másik lehetőség az interaktív kimutatásokra az adat- 
forráshoz történő , Filter" hozzáadása. Ez akkor lehet hasz- 
nos, ha az a cél, hogy a teljes lekérdezés végeredménye 
leválogatódjon először, és csak azután történjen a szűrés 
valamilyen kritérium alapján, vagy olyankor, amikor az 
adott adatforrás nem támogatja a 0-os paramétereket a 
lekérdezésben. A , Filter" megadásához úgyszintén a Re- 
port Designer-t hívjuk segítségül. A Data nézetben a kivá- 
lasztott DataSet listája mellett található gombot megnyom- 
va, majd a Filter fület kiválasztva adhatjuk meg a szűrési 
feltételt. 


FE Dataset 





Guery ] Fields ] Data Options ] Parameters . Filters l 





Filters: 
Expression " Operator ! Value Jánd. al 
b -FieldsiRegion. Value - I " s 
4 E E 2] 
XX] 





További interaktivitást szolgálnak a kimutatásban elhelye- 
zett hyperlink-ek és a dokumentumtérkép (document map). 
A hyperlink-et Layout nézetben az adott táblázat egy szö- 
vegmezőjének kiválasztása után a jobb egérgombbal ki 
kell választani a tulajdonságok lapot, majd megnyomni az 
Advanced gombot. Itt a Navigation fülön tudjuk beállítani a 
szükséges hyperlink-et, könyvjelzőt stb. 

A dokumentumtérkép beállítási lehetőségét a 7. ábrán ta- 
láljuk meg. 


A varázsló nem minden 

Meg kell említeni még, hogy ugyan az elején a varázsló 
használatát vettük igénybe a gyorsabb haladás érdeké- 
ben, de ugyanezt egy üres kimutatásprojektből kiindulva is 
el lehetett volna készíteni, persze korántsem ilyen gyorsa- 
sággal és hatékonysággal. 


] 
wv 
o 
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Kimutatás elérése JRL-en keresztül 
Az elkészült és publikált kimutatások egyik programozott 
elérési módja, amikor az URL-ben adjuk meg a megjele- 
néssel, paraméterekkel kapcsolatos információt. Például a 
következő URL a korábban elkészített jelentésünket a Terri- 
tory-Pacific paraméterrel hívja meg, és ezzel egyidejűleg 
le is tiltja a paraméter beállítási lehetőségét (nem jelenik 
meg egyáltalán a képernyőn), valamint tiltja a Toolbar meg- 
jelenését, és a nagyítást 15096-ra állítja. 


http: //localhost/ReportServer? /Sales Reports/ 
4 Sales by RegiongTerritory-Pacificg 

4 rc:Parameters-falsegrc:Toolbar-falseg 

4 rc:200m-150 


A részletesebb URL-szintaktika itt található meg: [4]. A 
szintaktika kiterjed a kimutatások keresésére, a kimeneti 
formátum megadására (pl. azonnal PDF-be exportálha- 
tunk), az eszköztár, a dokumentumtérkép engedélyezésé- 
re/tiltására. Ránavigálhatunk a dokumentum egy adott ré- 
szére, beállíthatunk kezdeti nagyítási értéket, adott sorszá- 
mú lapot jeleníthetünk meg. 


Kimutatás elérése webszolgáltatá- 
son keresztül 
A példák Ctt szintaktikával fognak megjelenni (de Visual 
Basic-re is átültethető analóg módon). A webszolgáltatást 
és ezzel együtt a korábban elkészített kimutatásunkat egy 
standard Windows Forms alkalmazásból fogjuk elérni. Ah- 
hoz, hogy alkalmazásunkban használhassuk a Reporting 
Services által nyújtott  webszolgáltatást, a következők szük- 
ségesek: 
mi Létre kell hoznunk egy proxy osztályt a webszolgálta- 
táshoz 
m Authentikáltatni kell a webszolgáltatás klienst a Re- 
port Server-rel 
mu Meg kell hívni az adott webmetódust, amely a szük- 
séges műveletet végrehajtja 


A proxy osztályra azért van szükség, mert a kliens és a web- 
szolgáltatás SOAP-üzeneteken keresztül kommunikál egy- 
mással, úgy, hogy az üzenetet, beleértve a paramétereket, 
XML-ben küldi át. A proxy osztály a paramétereket XML ele- 
mekké alakítja, majd ezt a SOAP-üzenetet küldi át a hálóza- 
ton. A SOAP szintjét a proxy elfedi, így ugyanúgy tudunk 
meghívni egy webmetódust, mintha az egy általunk megírt 
metódus lenne az alkalmazásunkban. Proxy osztály generá- 
lására két lehetőség is adódik. Az egyik a WSDL eszköz 
használata. A .NET Framework SDK tartalmaz egy WSDL 
(Web Services Description Language) eszközt, amely ké- 
pes egy ilyen proxy osztály generálására. Minimálisan meg 
kell adnunk a webszolgáltatásunk elérési útvonalát: 


wsdl.exe /language:CS 
4 http://myserver/reportserver/reportservice . asmx 


A fenti utasítás az aktuális könyvtárban készít nekünk egy 
Ct forrásfájlt ReportingService.cs névvel (ez a szolgáltatás 
neve). Bővebb paraméterezésről itt olvashat: [5]. Ezek után 
a proxy osztályt le kell fordítani assembly DLL-lé, és beten- 
ni az alkalmazásunkba. A továbbiakban ezt az osztályt fog- 


juk referenciaként használni. A második módszer a proxy 
osztály létrehozására a VS.NET fejlesztőeszköz maga. A 
különbség, hogy elvégzi automatikusan a proxy osztály 
projektbe való integrálását, felveszi referenciába a System. 
Web.Services.dll-t, amit az első módszernél nekünk kell 
majd elvégezni. Ekkor nincs más teendőnk, mint a Project) 
Add Web Reference menüpontot elindítva megadjuk a ko- 
rábban ismertetett webszolgáltatást leíró állomány (report- 
service.asmx) útvonalát. Majd a GO megnyomása után 
már meg is kaptuk azt a kis leírást, amely felsorolja a hasz- 
nálható 93 metódust a paraméterezésekkel, amit használ- 
hatunk majd. Elnevezhetjük a referenciánkat, ami nem lesz 
más, mint a proxy osztályunk leendő névtere. Az Add 
Reference hatására elkészül a proxy osztályunk, és hoz- 
záadóik a System.Web. Services. all is. 


using myNamespace .myReferenceName ; 


ReportingService rs - new ReportingService() ; 


Ezek után authentikáltatni kell a kliensünket. Erre vagy 
Windows-authentikációt, vagy Basic-authentikációt hasz- 
nálhatunk, az IIS Report Server virtuális könyvtárának biz- 
tonsági beállításától függően. 


// Windows authentikáció esetén 
rs.Credentials -— 
System.Net.CredentialCache.DefaultCredentials; 


// Basic authentikáció esetén 
rs.Credentials -— new 
System.Net.NetworkCredential ( "username" , 
"password" , "domain" ); 


Ha el akarjuk kerülni a HTTP: 401-es Access Denied hiba- 
üzenetet, akkor mielőtt bármilyen webmetódust meghív- 
nánk, állítsuk be a Credentials tulajdonságot. Ha van rá 
mód, használjunk Windows-authentikációt inkább, ha 
nincs, futásidőben kérjük be, mellőzük a Credential-ök fájl- 
ban való tárolását, ha mégis szükséges, akkor a Win32 
Crypto API-t használjuk hozzá. Innentől kezdve csak a mű- 
veletek elvégzéséhez szükséges webmetódusokat kell hí- 
vogatni. Ilyen például a Render() metódus, amelynek a se- 
gítségével feldolgozhatunk egy elkészített kimutatást, majd 
adott formátumban visszanyerhetjük, ezt egy byte[] tömb- 
ben adja vissza a metódusunk. Bővebben a Render() me- 
tódusról itt olvashatunk: [6]. Első lépésként elő kell állíta- 
nunk a metódusunk argumentumait, a kimutatás útvonalát, 
a megjelenítési formátumot (célszerűen HTML 4.0-t válasz- 
tottam, így a drill-down kimutatásunk interaktív lesz). A 
Devicelnfo [7] paraméterben megadhatunk egy XML állo- 
mányt, amely formátumspecifikus megjelenítési beállításo- 
kat tartalmaz. Jelen esetben így tiltjuk le a Toolbar megjele- 
nítését, így nem lehet a Territory paramétert kézzel beállíta- 
ni. Hasonló elvet alkalmaztunk az URL-es eléréskor is. 


byte[] result — null; 
string reportPath — 
"/Sales Reports/Sales by Region"; 
string format - "HTML4.O"; 
string historyID - null; 
string devInfo -— 8"cDevicelnforcToolbar:False" 4 
e€"c/Toolbar:c/Devicelnfo2" ; 
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A következő lépés a paraméterek megadása, amely egy 
ParameterValue osztályból képzett tömbbel történik. Mivel 
egy paraméterünk van csak (Territory), ezért egy egyelemű 
tömböt adunk át. 


ParameterValue[] parameters-new ParameterValue[1] ; 
parameters[0] - new ParameterValue( ) ; 
parameters[(0] .Name — "Territory"; 

parameters[0] .Value — "Pacific"; 


A továbbiakban megadhatnánk az adatforráshoz tartozó 
Credential-t, illetve egy sor jelenleg nem lényeges paramé- 
tert (a feldolgozás alatt keletkezett figyelmeztetések, kódo- 
lási beállítást, MIME-típust, a kibontható jelentésrészeket, a 
kimutatástörténethez tartozó paramétereket, a feldolgozási 
állapot információit). 


DataSourceCredentials[] credentials -— null; 
string showHideToggle -— null; 

string encoding; 

string mimeType; 

Warning[(] warnings - null; 

ParameterValue[] reportHistoryParameters — null; 
string[([] streamIDs — null; 
rs.SessionHeaderValue - new SessionHeader( ) : 


Ezután meghívjuk a Render() metódust a korábban beállí- 
tott paraméterekkel, és visszakapjuk az eredményt egy 
byte[] tömbben. 


try 
( 
result - rs.Render(reportPath, format, 
historyID, devInfo, parameters, credentials., 
showHideToggle, out encoding, out mimeType, 
out reportHistoryParameters, out warnings, 
out streamIDs); 
J 
catch (SoapException eSoap) 
( 
MessageBox . Snow(eSoap.Detail . OuterXml1 ) ; 
? 


A keletkezett eredményt egy FileStream-en keresztül a pél- 
da kedvéért a C:(Weport.htm állományba írhatjuk. 


try 
( 


FileStream stream - 

File.Create(€"C:NXReport.htm", result.Length) ; 
stream.Write(result, O, result.Length) ; 
stream.Close(); 


§ 
catch (Exception eFile) 
( 


MessageBox . Snow(eFile.Message) ; 


, 


A végén pedig, csak a gyors és egyszerű teszt kedvéért, 
felrakhatunk a Windows Forms alkalmazásunk űrlapjára 
egy COM-os WebBrowser kontrollt, hogy megnézhessük a 
saját űrlapunkon az eredményt. Ehhez a vezérlőhöz elké- 
szül egy COM csomagoló osztály (axWebBrowser), amely- 
nek a Navigate() metódusában megadjuk az elkészült 
HTML állomány elérési útvonalát (most fájlszinten). 





object flags - Type.Missing; 
object targetFrameName - Type.Missing; 
object postData - Type.Missing; 
object headers - Type.Missing; 
axWebBrowser1.Navigate(6"C:NXReport.htm" , 
ref flags, ref targetFrameName, ref postData, 
ref headers); 


Persze a fentieken túl bármit használhatunk a végső formá- 
tum megjelenítésére (a legkülönfélébb HTML-megjelenítő 
vezérlőktől az Excel munkafüzeteken át az Acrobat megje- 
lenítőkig, széles a skála). A megfelelő működéshez a 
VS.NET designer által automatikusan importált névtereken 
felül a következőket kellett felvenni: 


using AxSHDocVw; // WebBrowser kontrol csomagoló 
using WindowsApplication1.RS; // webszolgáltatás 
using System.Web.Services.Protocols;//SOAP kivétel 
using System.IO; // FileStream műveletek 


A WindowsApplication1-et és az RS-t (a webszolgáltatás 
referenciájának a neve) értelemszerűen a tesztprojektünk- 
nek megfelelően kell beállítani. A 15. ábrán jól látszik a Win- 
dows Forms projektünk végeredménye. 


Sales by Region 





[B Accessory 31035.47 Ft 17 069.51 Ft 13965.96 Ft 
Bike Racks 15 960,00 Ft 877800 Ft 718200 Ft 
Bottles d Cages 49900 Ft 27445 Ft 224,55 Ft 
Tires éz Tübes 11.45 Ft 6.30 Ft 5.15 Ft 
Cleaners 72345 Ft 39790 Ft 32555 Ft 
Hydration Pack 505908 Ft 278249 Ft 227659 Ft 
Helmet 878249 Ft 483037 Ft 395212 Ft 
G8ike 2105 46045 Ft 1.558 04073 Ft 547 41972 Ft 


15. ábra Saját Windows Forms alkalmazá- 
sunk kimutatásmegjelenítője webszolgál- 
tatáson keresztül 


MÁTHÉ ZOLTÁN 
matbezabsi.bu 
MCSD, SOL Server MVP 
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Reporting Services Books Online 
http;/ / tínyuri.com/ys3e8 


(1). http; /tinyuri.com/ 2ftpn 
[2]. httpz//tinyuricom/29h4u 
[3]. http;// tinyurl.com/ 3aBfg 
[4] http://tinyuri.com/ 38pj7 
[5]. http;//tinyuricom/ 3f3cn 
[6]. http://tinyuricom/ 3f57x 
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Kiszolgálópark 
üzemeltetése 


A VAS 


A kiszolgálók telepítéséről, használatáról, hibajavításáról 


sok cikket olvastam, a kiszolgálók üzemeltetéséről 


szóló információkat ellenben meglehetősen nehéz össze- 


szedni. Ez a cikksorozat ennek a hiánynak a pótlására 


született meg. Ebben a fejezetben azt elemzem, milyen 


legyen és mire jó a kiszolgálóhardven 


Egyáltalán: miért vegyünk kiszolgálóhardvert? 


hardver az amibe belerúghatsz. — szoktuk mon- 

dani. Nos, a cikksorozat mostani második része e 

rugdosódás célpontjával, a ,vassal" foglalkozik. 
Szó esik majd arról, hogy milyen különböző elvárások vo- 
natkoznak egy PC-re és egy kiszolgálóra. Milyen lépéseket 
tesznek a gyártók a kiszolgálóhardverek tervezésekor. Meg- 
vizsgáljuk, hogy mi határozza meg egy kiszolgáló teljesít- 
ményét. Szó esik a megbízhatóság növelésére tett lépések- 
ről, valamint a gyártók különböző támogatási formáiról. 


Minek vegyünk kiszolgálót? 


szerű PC-k kiszolgálói feladatkörben. Sem a cégveze- 
tés, sőt sokszor az üzemeltetés sincs tisztában azzal, 
hogy milyen alapvető különbségek vannak egy végfel- 
használói és egy kiszolgálói szerepre szánt PC között. 

A leggyakoribb válasz erre az, hogy: , Tulajdonképpen bár- 
milyen PC-re telepíthetők a kiszolgálóalkalnazások, csak 
az install-CD-t kell betenni, és már megy is." Ez a szemlélet 
egészen az első felbukkanó rejtélyes és váratlan problé- 
máig tartható is lehet. Előbb-utóbb azonban váltani kell. A 
szemléletmódban és a hardverben is. 

Miben különböznek a PC-vel és a kiszolgálóval szembeni 
elvárásaink? Az alábbi táblázatban a leggyakoribb haszná- 
latbeli különbségeket foglalom össze (természetesen ezek 
általános használatra vonatkoznak, kivételek létezhetnek). 


egy felhasználó használja több felhasználó használja 
a felhasználó a felhasználók távolról 
. a konzolon keresztül éri el (hálózaton keresztül) érik el 


Még ma is sok kisebb-nagyobb cégnél üzemelnek egy- Hi 














nem folyamatos (365 x 24 órában 
üzemben haszi folyamatosan üzemel 
nem feltétlei HE hálózatra E 
hálózatra kötve van kötve 





viszonylag csendes működés viszonylag zajos működés 





Természetesen e lista tetszőleges elemekkel tovább is bővíthető. Ám már 
a fenti kiragadott szempontok alapján is belátható, hogy a más jellegű 
használatra speciális hardvereszközök használatára lehet szükség. 


Milyen szempontok alapján 
válasszunk hardvert? 


Az egyik kiemelt szempont az ár. 

Egy PC és egy kiszolgáló ára között a különbség akár há- 
romszoros, nyolcszoros is lehet. Vajon megéri-e ezt a befek- 
tetést a kiszolgáló? Mi az a többletérték, amit a hardvergyár- 
tó ezért nyújt? Amit az ár vizsgálatakor célszerű figyelni, az 
a Total Cost of Ownership 
(TCO), azaz nemcsak a vétel- 
árat, hanem az eszköz élettar- 
tama során várható egyéb 
költségeket is magában fogla- 
ló ,birtoklási költséget" is ér- 
demes megvizsgálni. 





Már van hol... 


..de mivel is? 


A következő szempont a teljesítmény. 

Vajon tényleg tudjuk, hogy mit takarnak a különféle hangza- 
tos számok? A teljesítmény komplex tulajdonság, több 
részegység együttműködése szükséges hozzá. Mérésére 
különféle tesztorogramok léteznek, melyek számos jellem- 
zőt mérnek, ezek alapján lehet a különféle eszközöket 
összehasonlítani. A teljesítményt célszerű az egyes kom- 
ponensek szintjén megvizsgálni, így az igényeknek jobban 
megfelelő eszközt tudjuk kiválasztani. 

A megbízhatóság is kiemelt szempont kell(ene) hogy le- 
gyen egy kiszolgáló kiválasztásakor. Ezeket az eszközöket 
sokan használják, így az esetleges hardveres meghibáso- 
dások, illetve a bizonytalan működésből eredő szolgálta- 
tászavarok kihatása igen nagy is lehet. Sok helyen a szol- 
gáltatás kiesése konkrét anyagi veszteséget jelent, ezeken 
a helyeken könnyebben kimutatható, hogy mennyibe is ke- 
rül az állásidő. 


A gyártói támogatás mint szempont. 
Melyek és mire használhatók azok a támogatási formák, 
melyeket a hardvergyártó ad a különféle eszközökhöz. 
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Milyen szempontok alapján készítik 
fel a gyártók a kiszolgálóhardvere- 
ket a feladatkörök ellátására? 


Tervezési szempontok 

A kiszolgálóknál már a tervezőasztalon figyelembe veszik a 
kiszolgálókkal szemben támasztott követelményeket. Nem- 
csak szabványos alkatrészekből rakják össze a kész gé- 
pet, hanem erre a feladatra, környezetre tervezett hardver- 
elemeket is felhasználnak. A különféle kiegészítők, perifé- 
riák illesztését is kipróbálják, ezeket egymáshoz is illesztik 
szükség szerint. 


Teljesítmény (vagy másképp: performancia) 
Lássuk a fő részegységeket és azoknak a teljesítményre 
gyakorolt hatásait: 


PROCESSZOR 

Sokan azt gondolják, hogy az egyik meghatározó mérő- 
szám a sebesség. (Szerintük egy 1 GHz sebességű pro- 
cesszor nagyobb teljesítményű, mint egy 800 kHz-es. Ez 
nem feltétlenül van így!) 

Egy processzor működését számos tényező határozza 
meg: a processzor működési elve, utasításkészlet, gyorsí- 
tási technológiák, hogyan működhet együtt több pro- 
cesszor. 


MEMÓRIA 

Itt sem csak a méret a lényeg! Fontos még emellett a mű- 
ködési elv, az elérési idő, a sávszélesség, az I/O sávszéles- 
ség, a processzorsebesség. 


GYORSÍTÓTAR (CACHE) 
Típus, méret, sebesség, elérési idő a kulcsadatok. 


HÁTTÉRTÁRAK 
A háttértárak mérete, elérési sebessége, szervezése, tech- 
nológiája az, amit figyelembe kell venni a kiválasztáskor. 


BUSZARCHÍTEKTÚRA 

A részegységek összekapcsolására különféle buszrend- 
szerek léteznek. Ezek teljesítménye is alapjaiban meghatá- 
rozza egy kiszolgáló teljesítményét. A busz sebességének 
növelése emeli a teljesítményt. Természetesen ekkor mind 
a processzornak, mind a busznak támogatnia kell a na- 
gyobb sebességet. 

Egy rendszer teljesítményének korlátja a leggyengébb 
részegységében kereshető, ez a szűk keresztmetszet az 
,Üvegnyak". (Hiába van egy nagyon gyors processzorom, 
ha mellette nagyon lassú memória van, akkor a pro- 
cesszor akár idejének 90 százalékát is várakozással tölti, 
gyorsabb processzorral sem érhető el érezhető teljesít- 
ményjavulás.) 


Tekintsük át, h8) a kiszolgálókat alkotó 
egyes részegységek miben térnek el a bagyományos 
PC-k elemeitől: 


PROCESSZOR 
Az Intel processzor esetén a sebességében nincs sok kü- 
lönbség a PC-kben és a kiszolgálókban található típusok 


között. A cache méretében azonban már jelentős eltérése- 
ket találhatunk. Egy mai modern kiszolgálóprocesszorban 
256-512 kb L2 és 1024-4096 kb L3 cache található. 
Fontos tulajdonság a Hyper threading technológia haszná- 
lata. Ezzel a processzor virtuálisan több processzornak lát- 
szik az operációs rendszerben, ami körülbelül 30-4099-nyi 
teljesítménynövekedést hoz a konyhára, sőt például a Win- 
dows 2003 kiszolgálók ezt a technológiát operációs rend- 
szer szintjén is támogatják, még optimálisabb kihasználást 
téve lehetővé. (Régebbi operációs rendszerek két fizikai 
processzort látnak, így osztják el a munkát közöttük, míg a 
Windows 2003 meg tudja különböztetni a virtuális és a fizi- 
kai processzorokat, így még jobban el tudja osztani felada- 
tokat közöttük.) 

Külön érdekességet jelentenek a Xeon DP és a Xeon MP 
processzorok, melyek speciálisan a többprocesszoros ki- 
szolgálókba terveztek. Ezek segítségével valódi többpro- 
cesszoros kiszolgálókat építenek a gyártók, melyekkel to- 
vábbi teljesítménynövekedést lehet elérni. 


MEMÓRIA 

A memória általában az egyik tipikus szűk keresztmetszet 
szokott lenni. Ma már viszonylag nagy memóriák is elérhe- 
tő áron megvehetők, így nem ritka a 2-4 GB memória 
kiépítettségű kiszolgáló sem. PC-ket is lehet ekkora me- 
móriával megtölteni, ám ott többnyire a memóriakezelés, 
illetve a busz sebessége, szélessége hagy maga után kí- 
vánnivalót. A kiszolgálóknál ügyelnek arra, hogy a memó- 
ria elérési sebessége összhangban álljon a processzor 
sebességével. 


HATTÉRTÁR 

A PC-kben ma is többnyire az IDE/ATA felületű diszkek a 
legelterjedtebbek. Ez a technológia rengeteget fejlődött, 
olyannyira, hogy egyes, elsősorban kisebb teljesítményű 
kiszolgálókban is felhasználják ezeket. A kiszolgálókban 
általában SCSI, újabban a Serial ATA, illetve a réz alapú 
Fibre felületű HDD-k találhatóak meg. Ezek nagy teljesít- 
ményt nyújtanak, gyors elérési idővel rendelkeznek, az 
MTBF-értékük általában nagy. 

Ezeket azután valamiféle hibatűrő szervezésben célszerű 
konfigurálni. A legelterjedtebb hibatűrő szervezési techno- 
lógia a RAID, amit a legtöbb kiszolgálógyártó hardveresen 
is támogat, azaz a lemezvezérlő menedzseli a diszkeket, 
levéve a terhet az operációs rendszer és a CPU válláról, 
ezzel is növelve a rendszer teljesítményét, megbízhatósá- 
gát. (A firmware az operációs rendszer nélkül is képes pél- 
dául befejezni az adatok kiírását egy esetleges rendszerel- 
szállás során.) 


BUSZARCHÍTEKTÚRA 

A kiszolgálókban sokféle buszrendszer megtalálható. 
Ezeknek a teljesítményre gyakorolt hatása talán a legfonto- 
sabb különbség a kiszolgáló és egy hagyományos PC kö- 
zött. A backside-busz a processzor és a cache közötti kap- 
csolatot valósítja meg, a frontside-busz pedig a pro- 
cesszort az egyéb részegységekkel köti össze. Egy jó ki- 
szolgálóban ma már akár 533 MHz sebességű FSB is meg- 
található. A memóriabusz nevéhez hűen a memória illesz- 
tését végzi. A perifériák az I/O buszrendszereken keresztül 
érhetőek el. A leggyakrabban támogatott I/O buszrendsze- 
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rek: ISA, EISA, PCI, PCI-X, PCI-X2.O, InfiniBand, PCI 
Express, AGP, USB, FireWire. 

A nagy sebességű, illetve széles (64 bit, 66, 133 MHz) PCI- 
buszokat szinte kizárólag csak kiszolgálóhardverekbe épí- 
tik be. A nagy sebességű PCI-X buszra 64 bites, 133 MHz 
órajelű eszköz is kerülhet, ami elméletileg akár 1067 MB/s 
átvitelre is képes, szemben a PC-kbe szerelt 32 bites, 
33 MHz sebességű busz 133 MB/s elméleti maximum telje- 
sítményével. Ide kerülhet például nagy sebességű háttér- 
tárvezérlő, amellyel sok diszk (28-36) is gyorsan elérhető. 
További, csak kiszolgálókra jellemző gyorsítási lehetőség a 
több PCI-vezérlő használata, így egy kiszolgálóba több 
kártyát helyezhetünk el. További előnye még ennek a 
megoldásnak, hogy a kártyáknak nem kell osztozkodniuk 
egy PCI-vezérlőn, ami szintén növeli a teljesítményt. 


HÁZ, BEÉPÍTHETŐSÉG 
A folyamatos üzemre felkészített ház is sokat jelent. A ben- 
ne elhelyezkedő részegységek hűtéséről is gondoskodni 
kell. Ezenkívül méret, elhelyezhetőség szerint többféle 
szempontot is figyelembe vesznek: 
mu Lehet rack-be szerelhető kivitelű, így könnyen, egy- 
szerűen használható nagyvállalati környezetben. 
mu Lehet sok diszket befogadó ház, állománykiszolgálók 
befogadására. 
m Lehet nagy hely a házban speciális, teljes hosszúsá- 
gú kártyák befogadására. 


Meg kell jegyezni, hogy általában valamely célra speciali- 
zált házban lehet a kiszolgálót kapni, olyan univerzális ház, 
amely minden igényt egyszerre elégít ki, viszonylag ritkán 
fordul elő. 


Megbízbatóság 

Külön kiemelt fontosságú kérdés a kiszolgálók üzembiztos- 
sága. A kiszolgálókat 365 x 24 órás folyamatos üzemre ter- 
vezik, ezért különféle technológiákat alkalmaznak, úgymint: 


NAGY MEGBÍZHATÓSÁG 

A részegységekkel szemben magasabb minőségi igénye- 
ket támasztanak, mint egy átlagos PC-nél. A részegysége- 
ket nem csak külön-külön, hanem egymással összeépítve 
is tesztelik. Egyre több intelligens hardverfigyelő lehetősé- 
get építenek be az eszközökbe, melyek üzem közben mo- 
nitorozzák, tesztelik a rendszert, így képesek a hibák előre- 
jelzésére is. 


REDUNDANCIÍA 

Az egyes kritikus elemeket duplikálják, így meghibásodás 
esetén sem áll le a kiszolgáló. Leggyakrabban a hűtőventi- 
látorokat, tápegységeket, diszkeket kettőzik meg. A 
passzív eszközökből egyszerűen többet építenek be (ven- 
tilátor, tápegység), alkalmazhatók azonban intelligens 
megoldások is, például a ventilátorok sebességszabályo- 
zása a hűtési igénynek megfelelően stb. 

A diszkek hardveres hibatűrő megoldásai is elterjedtek. Lé- 
tezik egyszerű tükrözés vagy valamilyen magasabb szintű 
RAID-megoldás. Használnak még úgynevezett melegtarta- 
lék diszket is, ez a rendszerbe beépített --1 diszk, amely 
valamelyik másik diszk meghibásodásakor automatikusan 
átveszi annak a helyét. 


A memóriamodulok meghibásodásának jelzésére és hiba- 
javításra is többféle megoldást alkalmaznak. Legelterjed- 
tebb a paritásgenerálás és -vizsgálat. Egy másik biztonsá- 
gi tényező a melegtartalék. Itt a diszkekhez hasonlóan egy 
plusz memóriamodul van beépítve a rendszerbe, amely ké- 
pes átvenni egy meghibásodott memóriamodul szerepét. A 
nagyvállalati kiszolgálókban létezik memóriatükrözés, illet- 
ve RAID-szervezésű memóriakezelés is, ezek a megoldá- 
sok már igen jó hibatűréssel rendelkeznek. 

A még biztonságosabb működés érdekében a hálózati 
adapterek is tükrözhetők, ilyenkor az egyik adapter (vagy 
hálózati szegmens, esetleg külön-külön aktív eszközre köt- 
ve az aktív eszköz) hibája esetén is elérhető marad a ki- 
szolgáló. A diszkvezérlők is duplikálhatók, ez a megoldás 
még nagyobb rendelkezésre állást valósít meg. 

Az alaplapi BIOS is megkettőzhető, ekkor nem csak a 
BIOS-hibákat, hanem a néha előforduló BIOS-flash-frissíté- 
si hibákat is kordában lehet tartani. 


GYORS JAVÍTHATÓSAG 

Egyre nagyobb teret hódítanak az üzem közben cserélhe- 
tő részegységek. Ezek, amint azt a nevük is mutatja, a ki- 
szolgáló leállítása nélkül is cserélhetők (Hot Plug technoló- 
gia), így még kevesebb leállásra van szükség az esetle- 
ges hardvermeghibásodások esetén. Egy ventilátor vagy 
egy tápegység cseréjekor a kiszolgálón futó operációs 
rendszer nem is feltétlenül szerez tudomást a javításról. 
Azonban például egy Hot Plug PCI-kártya cseréjéhez spe- 
ciális eszközmeghajtók telepítése, illetve néhány szabály 
betartása is szükséges. A legújabb operációs rendszerek, 
mint például a Windows 2003, már tartalmaznak Hot Plug 
eszköztámogatást is. Egy nagyvállalati kiszolgálóban me- 
net közben cserélhetők lehetnek a ventilátorok, tápegy- 
ség, diszk, PCI-kártyák (pl. hálózati kártya, lemezvezérlő), 
memóriamodulok, sőt egyes modellekben maguk a pro- 
cesszorok is. Ilyen funkciókkal felszerelt kiszolgálók üze- 
meltetése esetén nagyon fontos a gyártó utasításainak 
betartása! A józan ész határain belül célszerű maradni, 
azaz nem célszerű például egyszerre az összes pro- 
cesszort vagy memóriamodult kivenni, akkor sem, ha me- 
legen cserélhető. . . 


MODULÁRIS FELÉPÍTÉS 

Egy kiszolgálónál fontos szempont lehet a méretezhető- 
ség. Költséghatékony lehet, ha csak azokat a részegysé- 
geket vesszük meg, amelyeket tényleg használni fogunk. 
Később viszont az igények változásával jól jöhet, ha a ki- 
szolgálónk bővíthető, illetve egyes egységei cserélhetők, 
és nem kell az egészet újra váltani. Például egy dinamiku- 
san fejlődő adatbázis-kiszolgálót kezdetben megvásárol- 
hatunk két processzorral, majd később (ha vásárláskor 
gondoltunk erre) egyszerűen bővíthetjük négy processzor- 
ra, illetve növelhetjük a memóriáját is. Az állománykiszolgá- 
lónkhoz idővel újabb diszkeket köthetünk a felhasználói 
igényeknek megfelelően. A redundáns eszközöket is be- 
szerezhetjük később, lehetőségeinkhez mérten (pl. re- 
dundáns tápegység, memória stb.) 
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KÖNNYŰ SZERELHETŐSÉG ÉS 
SZERVÍZELHETOSEG 

A kiszolgálókat tapasztalatom szerint viszonylag ritkán kell 
szerelni, de akkor nagyon jól jönnek azok az ötletes megol- 
dások, melyek a szervizmérnök életét könnyítik meg. Ezek 
a néha pofonegyszerű megoldások nemcsak a hibalehető- 
ségeket csökkentik, hanem a szereléssel töltött időt (a po- 
tenciális állásidőt) is. Egy modern kiszolgálóhardver fizikai 
kialakítása átlátható, ábrákkal, színekkel jelölt lehet, az 
egyes részegységek könnyen, akár szerszámok nélkül is 
kivehetők, beépíthetők. Az újabb részegységek könnyen 
és helyesen beilleszthetők, a különféle kábelek és egyéb 
csatlakozók jól illeszthetők, megfelelő méretűek, könnyen 
és egyértelműen csatlakoztathatók, a csatlakozások köny- 
nyen bonthatók. Az eszköz hűtése, légáramlása megfelelő, 
jól átgondolt. 


BIZTONSÁGI FUNKCIÓK 
Egyes kiszolgálók különféle biztonsági funkciókat is tartal- 
mazhatnak: 

m fizikai hozzáférés védelme: a ki-be kapcsolás, a ház 
nyitása, illetve a részegységek, diszkek kivétele 
ellen védhető általában valamilyen kulcsos megol- 
dással, 

m egyes speciális kártyákat, eszközöket speciális mó- 
don védhet, megakadályozva az adatok kinyerését 
(pl. PKI-hez kulcstároló kártyákat célszerű védeni). 


IÁVOLI MENEDZSMENT 

Egyre több kiszolgáló tartalmaz beépítve valamilyen táv- 
menedzselési szolgáltatást, melynek segítségével a távoli 
telephelyen-kiszolgálóhelyiségben elhelyezett kiszolgáló fi- 
zikai jelenlét nélkül is kezelhető. Ilyen lehet a konzol (billen- 
tyűzet, monitor, egér) távoli átvétele, floppy, CD távoli átvé- 
tele, különféle diagnosztikai funkciók futtatása-elindítása. 
(Létezik olyan, saját tápellátással rendelkező menedzs- 
menteszköz, mellyel a kikapcsolt, illetve meghibásodott ki- 
szolgáló állapota is figyelemmel kísérhető, sőt beavatkozá- 
sok is eszközölhetők.) 


szoftveres támogatás 
A kiszolgálókhoz a gyártó különféle programokat mellékel. 
Ezek egy része jár a hardverhez, másokért külön licencdíi- 
jat kell fizetni. 
Ezek lehetnek: 
m eszközmeghajtók, frissítések (Driver, Firmware), 
u a kiszolgáló telepítését, konfigurálását támogató, 
végző programcsomagok, 
m a kiszolgáló tásmenedzselését megvalósító progra- 
mok, 
m a kiszolgáló állapotáról különféle információkat nyújtó 
programok (monitorozás). 


Támogatás 
Szinte mindegyik kiszolgálógyártó különféle támogatási 
csomagokat ajánl és forgalmaz a kiszolgálóihoz. 
Ezek lehetnek, a teljesség igénye nélkül: 
m emeltszintű szerviz, 
mu terméktámogatás, 
Mu termékkövetés, 


szoftverfrissítések, 
tanácsadás, 

telepítés, beépítés, 
segédanyagok, kellékek. 


A kiszolgálók csoportosítása 
A kiszolgálókat többféleképpen csoportosíthatjuk. 


Általános célú kiszolgálók 
Mindennapi kiszolgálónk lehet, ha nincsenek különleges 
igényeink. 


Kisvállalkozások (Small Business) 

Ez azoknak ajánlott, akik mindent egyben szeretnének lát- 
ni. Itt általában a szerényebb teljesítmény, kedvezőbb ár is 
fontos szerepet játszik. 


Gyors javítbatóság 
Sokféle redundáns részegységet tartalmaz. Nagy megbíz- 
hatóságú környezetbe ajánlott. 


Nagyvállalat (Enterprise) 
Nagyágyú, nagy teljesítményt nyújt, jól ssálázható, megbíz- 
ható eszköz. Az ára is tükrözi a pozícióját. 


Speciális feladatok 
Speciális kivitellel rendelkező kiszolgálók különleges 
feladatokra. 
mu Mobil vagy speciális ipari környezetbe szánt, meg- 
erősített fizikai kivitel. 
m Speciális csatlakozások, perifériák célfeladatok ellá- 
tására. 


Moduláris kiszolgálók és pengék 

(blade szerverek) 

Modul rendszerű, rackbe építhető kiszolgálók, elsősorban 
nagy mennyiségű kiszolgáló elhelyezésére használhatók. 


Az I/O-modulok, tápegységek, diszkek, processzor vagy 
szerverkártyák, külön-külön igény szerint szerezhetőek be, 
konfigurálhatóak menedzselhetőek. 


A kiszolgálók csoportosítása a raj- 
tuk futó szolgáltatások alapján 


ALKALMAZÁSKÍSZOLGÁLÓ 

Kiszolgálóoldali alkalmazások futtatására használható. Ál- 
talában a klasszikus kliens-szerver programok ilyenek. 
Meghatározó tényező itt a memória- és processzorigény, 
jellemzőek a multiprocesszoros hardverek. 


ADATBAZÍS-KÍSZOLGÁLÓ 

Az adatok tárolására használható. Sok esetben az üzleti lo- 
gikát a teljesítmény növelése érdekében külön alkalmazás- 
kiszolgálóra teszik, az adatbázis-kezelő részére dedikál- 
nak kiszolgálót. 

Memória- és háttértárigénye meghatározó. A nagy tömegű 
adatok gyors eléréséhez szükség lehet nagy sebességű 
I/0-eszközökre is. Jellemző lehet a külső háttértár. 
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ALAPÍNFRASTRUKTÚRA 

Alapvető kiszolgálófunkciók megvalósítása. Ezek általában 
nem igényelnek különösen sem memória-, sem pro- 
cesszor-, sőt általában diszkkapacitást sem, és a hálózati 
sávszélességük sem meghatározó, viszont elvárás a nagy 
rendelkezésre állás, hiszen alapvető szolgáltatásokat biz- 
tosítanak (pl. DNS, DHCP, azonosítás (DC) stb.). 


INFRASTRUKTÚRA 

A hálózati infrastrukturális funkciók megvalósítására szol- 
gálnak. Igényük hasonló lehet az előző kategóriához, de 
szóba jöhetnek speciális hardverelemek is, elsősorban I/O- 
eszközök (bridge, proxy, router stb.). 


FELÜGYELET/MENEDZSMENT 

A nagy tömegű kiszolgáló/kliens, illetve a magas rendelke- 
zésre állás igénye teszi szükségessé ezeket az eszközö- 
ket. Ezek általában nem igényelnek különleges hardver- 
komponenseket, a kiszolgálók és a kliensek felügyeleti-me- 
nedzsment szoftverei, alkalmazásai futnak rajtuk. 


MENTÉS 

Ahogyan egyre nagyobb értékű adatok egyre komplexebb 
kiszolgálókörnyezetben kerülnek elhelyezésre, úgy nő, bo- 
nyolódik a mentési alrendszer is. Egyes helyeken kiemelt 
fontosságú a megfelelő mentési stratégia, itt a különféle 
mentési folyamatokra külön kiszolgálókat állítanak be. 
Hardverigényük az alkalmazott mentési megoldástól függ. 


ALLOMÁNYKÍSZOLGÁLÓ 

Egy másik klasszikus alapfeladat az állományok tárolása. 
Itt a fő cél az állományok minél gyorsabb elérése. Ehhez 
nagy teljesítményű I/O alrendszerre, gyors, biztonságos 
diszk-alrendszerre van elsősorban szükség. Jellemző lehet 
a külső, intelligens háttértár használata. Egyre nagyobb te- 
ret hódítanak az egybecsomagolt kiszolgálómegoldások 
(appliance), ahol egy célhardver beágyazott operációs 
rendszerrel célfunkciót valósít meg, így még nagyobb telje- 
sítmény érhető el. 


TŰÚZFAI 

Feladata a hálózat védelme, elválasztása más hálózati ré- 
szektől, hozzáférés elleni védelem. Ehhez általában több 
hálózati adaptert kell tartalmaznia. A VPN-, HTTPS-forga- 
lomhoz megfelelő számítási teljesítményre van szüksége, 
szempont lehet a gyors I/O-rendszer is. 


LEVELEZŐKISZOLGÁLÓ 

Feladata az elektronikus levélfogalom kezelése. 

Nagy teljesítményű I/O-rendszer, esetleg külső háttértár 
használata megfontolandó lehet. 


Lehet a kliensek és a más kiszolgálókkal történő kapcsolat- 
tartásra dedikált kiszolgálókat is beállítani. 


KOMMUNIKÁCIÓ 

Egyéb elektronikus kommunikációs szolgáltatások (cseve- 
gés, azonnali üzenetküldés, konferencia, videokonferencia 
stb.) üzemeltetésére használható. Terheléstől és az adott 
szolgáltatástól függő hardveren futhat. 


NYOMTATÓKÍISZOLGÁLÓ . 

Nyomtatók, nyomtatási sorok, nyomtatási munkák kezelése 
a feladata. 

Ma már viszonylag ritkán használnak közvetlenül a kiszol- 
gálóra kötött nyomtatókat. Általában a hálózatra kötött 
nyomtatók kezelésére használják. 

A gyors hálózati kapcsolat mellett fontos lehet a megfelelő 
méretű háttértár a nyomtatási sorok kiszolgálásához. 


WEBKISZOLGÁLÓ 

Webanyagok kezelésére használható. 

A klasszikus statikus oldalak mellett egyre több, dinamikus 
tartalommal rendelkező webkiszolgálót üzemeltetnek, egy- 
re több alkalmazást írnak úgynevezett vékonykliens-tech- 
nológiával, amikor az alkalmazás a webkiszolgálón fut, és a 
kliensek az alkalmazás felületét webböngészőn keresztül 
érik el. A multimédiás vagy szórt (streaming) webalkalma- 
zások is egyre inkább teret hódítanak. 

Terheléstől és feladatkörtől függ a megfelelő hardver. 
Speciális webkiszolgáló-farmok és az ehhez tervezett pen- 
gehardverek fedik le ezt a célterületet. 


Záró gondolatok 

A kiszolgálókon egyre több, egyre kritikusabb szolgáltatá- 
sok futnak. Kiválasztásuk, üzemeltetésük egyre komple- 
xebb feladat. Ehhez a feladathoz természetesen szakértői 
segítséget is igénybe lehet venni, sokszor azonban célsze- 
rű magunknak is a kiválasztás alapelveivel tisztában len- 
nünk. Cikkemmel, remélem, sokakat közelebb juttathatok 
ehhez a célhoz. 


MEGYESI BARNABÁS 

megyesi .barnabásao meb.bu 
üzemeltetésvezető 

MCSE. HP ASE 


A cikkben szereplő URL-ek: 


[1]. http:// www.hp.com/ products, servers, platforms/k 
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szolgáltatások 


MELYIKET HASZNÁLJUK ÉS MELYIKET NE? 


A szolgáltatásokkal kapcsolatban számos alapfokú és 


haladóknak szóló információt nyújtottunk a sorozat 


első részében. Most megpróbáljuk egyesével sorra venni 


egy frissen telepített VVindows Server 2003 


tartományvezérlő alapértelmezett szolgáltatásait. 


Használati utasítás ezen íráshoz 
Lássuk melyek azok a szolgáltatások amelyek feltétlenül kel- 
lenek, amelyek nélkül összedől a rendszer és mi az ami leál- 
lítható (vagy éppen muszáj letiltani), esetleg el is távolíthatjuk 
végleg. Minden rendszer más és más, ha csak a rendszerrel 
szemben támasztott követelményekből indulok ki, már akkor 
is érvényes ez a tétel. De igaz ez a hardver és a hálózat- 
ban/tartományban betöltött szerepek vonatkozásában is. 
Semmilyen az operációs rendszeren kívüli kiszolgáló vagy 
egyéb szoftver jelenlétével nem számolunk, nincs Exchange, 
ISA, SOL Server és egyéb komponensek sem. Elsősorban 
alapszintű tájékozódásra javaslom forgatni ezeket az oldala- 
kat, és egyúttal leszögezném, hogy a mentés nélküli, éles 
rendszeren ténykedők harakirit elkövető operációs rendsze- 
reivel kapcsolatban semmiféle kártérítésre nincs mód. 


Egy kis statisztika 

Számításom szerint egy friss Windows Server 2003 tarto- 
mányvezérlőnél (a telepített komponensektől némiképp 
azért függően) közel 100 szolgáltatás van. Ennek körülbelül 
a fele automatikus indítású, a manuálisan indíthatók száma 
32-35, a maradék (kb. 12-15) pedig le van tiltva alapértel- 
mezés szerint. Ha a bejelentkezés fiókja szerint nézzük meg 
a listát, akkor a Local System az aranyérmes, hiszen mind a 
Network Service, mind a Local Service fiók alkalmazása kü- 
lön-külön is csak kb. 9-10 szervizre jellemző, az összes töb- 
binek a helyben korlátlan hatalmú Local System fiók jut. Ha 
a mennyiségi fejlődést nézem az operációs rendszerekhez 
viszonyítva, akkor érdekes lehet az, hogy a Windows 2000- 
hez képest több mint negyven új szolgáltatás van az XP-ben 
és/vagy a Windows 2003 Serverben. Az utóbbiban egyéb- 
ként tíznél több olyan új szerviz van, amely korábban még 
sohasem szerepelt egy Windows operációs rendszerben 
sem, íme a tömörített lista: ASP.NET State Service, HTTP 
SSL, Message Oueue Triggers, Remote Administration 
Service, Remote Server Manager, Resultant Set of Policy 
Provider, Special Administration Console Helper, Terminal 
Services Session Directory, Virtual Disk Service, Web 
Element Manager, Windows Media Services, WinHTTP Web 
Proxy Auto Discovery Service, IAS Jet Database Access. 
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Az első 10 
Ebben a részben összesen 10 szervizt veszünk górcső alá. 
Közös tulajdonságuk az, hogy mind az újonnan (XP, Win- 
dows Server 2003) bevezetett Local Service fiókkal futó 
szervizek, amelyekről az előző rész alapján tudnunk kell 
már egy-két dolgot, de azért foglaljuk össze röviden: 
m gyengített jogosultsági körrel futnak, ami körülbelül 
megfelel egy átlagos felhasználói fiók lehetőségeinek, 
m a hétköznapi értelemben vett erőforrás hozzáférés 
(objektumokhoz) nem megengedett, 
m hálózati hitelesítés sem jár ehhez a fiókhoz, 
m és végül: nincs jelszavuk sem. 


Ha a Local Service fiók használata alapján csoportosítunk ak- 

kor a következő szolgáltatásokat lehet egy kalap alá venni: 
m Alerter 

Application Layer Gateway Service 

Remote Registry 

Smart Card 

TCP/IP NetBIOS Helper 

Telnet 

Uninterruptible Power Supply 

WebClient 

Windows Image Acauisition 

WinHTTP Web Proxy Auto-Discovery Service 


A részletezés előtt röviden szólnék az elnevezésekről: 

A szerviz neve után zárójelben a Windows Server 2003 ma- 
gyar nyelvű súgójában szereplő nevet jegyeztem be. A 
szerviz rövid neve az a név amely parancssorból például a 
,net start" parancs után következik. Annál a szerviznél, ahol 
nincs külön futtatható állomány, a processzt tartalmazó .dil 
szerepel, plusz az svchost.exe is, mint futattó alkalmazás. 
Ez utóbbi módszerről a sorozat előző cikkében volt szó. 


Alerter (Riasztás) 
A szerviz rövid neve: Alerter 
Az alkalmazás neve: alrsvc.dil (svchost.exe) 
Függés: Workstation szerviz 
Függesztés: — 
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Porthasználat: TCP: 2869, dinamikus; UDP: 1900 

Alapértelmezett indítás: letiltva 
Az Alerter szolgáltatással az adminisztratív üzenetek küldé- 
se történik. A felhasználók/számítógépek részére bizton- 
sággal, hozzáféréssel, replikációval, nyomtatással vagy pl. 
a felhasználói munkamenetekkel kapcsolatos riasztásokat 
küldhetnek a különböző alkalmazások (pl. a szünetmentes 
tápegységek szoftvereinek bevett szokása ez). Mindennapi 
használatban lehet akkor is, ha a Performance Monitor , fi- 
gyeli" a rendszerünket például hibakeresés céljából. Ekkor 
az általunk kiszemelt objektumok nem rendeltetésszerű mű- 
ködéséről az Alerter szerviz tudósíthat bennünket. 
Ahhoz hogy a feladó géptől a felhasználóhoz eljusson ez az 
üzenet, a Messenger (Üzenetküldő) szolgáltatásnak is futnia 
kell a felhasználó gépén. Ha az Alerter szolgáltatás le van ál- 
lítva vagy tiltva, akkor az üzenet csak helyben kézbesítődik. 


Application Layer Gateway Service 
(Alkalmazási réteg átjárószolgáltatása) 

A szerviz rövid neve: Alg 

Az alkalmazás neve: Alg.exe 

Függés: — 

Függesztés: Internet Connection Firewall; 

Connection Sharing 

Porthasználat: TCP: 21, dinamikus 

Alapértelmezett indítás: kézi, leállítva 
Az ALG új szerviz, érthető okokból a Windows 2000-nél 
még nem találkozhattunk vele, hiszen tulajdonképpen a 
Windows 2003/XP beépített tűzfala és az internet elérés 
megosztását végző alkalmazás kiegészítője ez a szerviz. 
Konkrétan a külső szoftverek protokollbővítményei számára 
nyújt opciókat, azzal, hogy lehetővé teszi, hogy a beépített 
tűzfalon átjuthassanak és az ICS mögött is működhessenek. 
Ezek a bővítmények így rendeltetésszerűen nyithatnak és 
változtathatnak portokat illetve IP címeket. Maga a Windows 
Server 2003 Standard es Enterprise változata egyetlen ilyen 
bővítménnyel rendelkezik, ez pedig az FTP protokollhoz tar- 
tozik. Amikor a szerviz kifelé menő FTP forgalmat tapasztal, 
kicsípi a csomagból azt a portszámot, amelyen a visszafelé 
forgalmazás történne, és ezt felhasználva egy dinamikus 
port átirányítást hajt végre az adatcsatorna részére. 
Ha leállítjuk vagy letiltjuk ezt a szolgáltatást, akkor a tűzfal és 
az internet megosztás nem fog működni, valamint a külső 
gyártók tűzfal szoftvereivel is hasonló gondjaink lesznek. 
Kézi indítású a szerviz alapállapota, így elvileg csak akkor 
indul el, ha valóban szükség van rá, de ha a fentiek alapján 
még sincs rá szükségünk, akkor nyugodtan letilthatjuk. 


Internet 


Remote Registry 
(Távoli rendszerleíró adatbázis) 

A szerviz rövid neve: RemoteRegistry 

Az alkalmazás neve: regsvc.dll (svchost.exe) 

Függés: Remote Procedure Call szerviz 

Függesztés: — 

Porthasználat: — 

Alapértelmezett indítás: automatikus 
Ez a szolgáltatás a távoli felhasználók számára nyújt hozzá- 
férést az adott gép regisztrációs adatbázisához. Egy tarto- 
mányban elsősorban az üzemeltető használja a kliens gé- 
pek felügyelete/kezelése során. Ezenkívül van még egy ér- 
dekes szerepe: a Windows Server 2003/XP valamelyik vál- 
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tozatát futattó távoli gépen az Eseménynapló egy-egy ese- 
ményének a tulajdonságlapján a Description illetve a 
Category mezőjének leolvasásához is szükséges. Ha ez 
nincs meg, akkor adja azt a levelezési listákon már többször 
felmerült hibaüzenetet az Eseménynapló, amelyet a felső 
képen is lehet látni a Description mezőben (az alsó képnél a 
különbséget az okozza, hogy elindítottam a szervizt). 


idod ei; 





.- Az Eseménynaplónak nem mindegy, hogy 
működik-e a Remote Registry szolgáltatás 


Persze, ha már a távoli eseménynapló elindításakor sem fut 
a szerviz, akkor már a naplóállományokat sem lehet kezelni. 
Ha viszont közben újraindítjuk a szervizt, akkor újra csatla- 
kozni is kell az adott géphez. 

Ha letiltjuk ezt a szolgáltatást, akkor már csak a helyi gépről 
érhető el a regisztrációs adatbázis, arról viszont továbbra is 
korlátozások nélkül. Biztonsági szempontból önálló gépen 
ennek mindenképpen van értelme, persze például egy tar- 
tományban a praktikum erősebb érv lehet a letiltással 
szemben. 


Smart Card (Intelligens kártya) 

A szerviz rövid neve: SCardSvr 

Az alkalmazás neve: SCardSvr.exe 

Függés: Plug and Play szerviz 

Függesztés: — 

Porthasználat: — 

Alapértelmezett indítás: kézi, leállítva 
Értelemszerűen az intelligens kártya használatot támogató 
szolgáltatásról van szó, amely akkor indul, ha egy kártyát 


gyömöszölünk az olvasóba. 
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Ha leállítjuk vagy letiltjuk akkor nem történik semmi extra 
fennakadás, csak annyi, hogy ez a támogatás nem áll ren- 
delkezésre. 


TCP/IP NetBIOS Helper 
(TEP/IP NetBIOS támogató) 

A szerviz rövid neve: LMHosts 

Az alkalmazás neve: Imhsvc.dll (svchost.exe) 

Függés: AFD Networking Support Environment, 

NetBIOS Over TCPAP TCP/IP Protocol Driver, IPSec 

Driver 

Függesztés: — 

Porthasználat: TCP: 139; UDP: 137, 138 

Alapértelmezett indítás: automatikus 
Ez a szolgáltatás fontos, sőt a legtöbb esetben még ma is 
nélkülözhetetlen: a TCP/IP feletti NetBIOS forgalomhoz, va- 
lamint a NetBIOS névfeloldási rendszer használatához 
szükséges. Ennek megfelelően például az állomány és 
nyomtató megosztás vagy a hálózati belépés, esetlegesen 
a DNS szolgáltatás sem működik megfelelően ha leállítjuk, 
vagy esetleg letiltjuk. Ez a szerviz gyakorlatilag a NetBT ki- 
terjesztése, ezért a NetBT-vel kommunikáló kliensek pl. a 
Redirector, Server, Netlogon vagy a Messenger szervizek 
sem , élnek" meg a hiányában, de pl. a tartomány alapú há- 
zirendekkel kapcsolatban is számíthatunk néhány problé- 
mára (pl. szoftvertelepítés). 





Telnet (Telnet) 

A szerviz rövid neve: TintSvr 

Az alkalmazás neve: tintsvr.exe 

Függés: Remote Procedure Call, NT LM Security 

Support Provider szervizek, TCP/IP Protocol Driver, 

IPSec Driver 

Függesztés: — 

Porthasználat: TCP 23 

Alapértelmezett indítás: letiltva 
A komoly hagyományokkal rendelkező és valószínűleg s0- 
kak számára jól ismert Telnet szolgáltatás a TCP/IP proto- 
kollkör egyik tagja. A kiszolgálón egy távoli munkamenet 
létrehozását teszi lehetővé, parancssorból. Hagyományai 
ellenére (vagy talán azért?) a Telnet protokoll bevallottan 
nagyon alacsony szintű adatvédelmet biztosít. A kliens és 
a kiszolgáló között minden adat, beleértve a jelszavakat is, 
egyszerű szövegként továbbítódik. Ugyan a Windows 
2000 Server óta a Telnet munkamenet használhat NTLM 
hitelesítést, így a helyzet valamivel jobb mint korábban, 
de ez még mindig édeskevés. A legjobb megoldás ha 
meghagyjuk a szervizt a gyári induló értéken, azaz letiltva 
(paranoiások pedig el is távolíthatják, pl. a SrvInstw.exe- 
vel [1]. 


Uninterruptible Bower Supply 
(Szünetmentes áramforrás) 

A szerviz rövid neve: UPS 

Az alkalmazás neve: ups.exe 

Függés: - 

Függesztés: — 

Porthasználat: — 

Alapértelmezett indítás: kézi, leállítva 
Csak a teljesség kedvéért említjük meg, mert szintén egyér- 
telmű a szerepe: a csatlakoztatott szünetmentes tápegysé- 


gek és az operációs rendszer kommunikációját valósítja 
meg. Összesen egy megjegyezni valóm van csak hozzá: 
amennyiben USB csatlakozású a szünetmentes tápegység, 
akkor bátran letiltható, ugyanis ez a szerviz csak a soros 
portokon képes dolgozni. Ha viszont az operációs rendszer 
egy soros porton működő UPS-t észlel, azonnal elindítja és 
automatikussá teszi az indító állapotát is. 


WebClient (WebClient) 

A szerviz rövid neve: WebClient 

Az alkalmazás neve: davclint.dil (svchost.exe) 

Függés: WebDav Client Redirector szerviz 

Függesztés: — 

Porthasználat: TCP 80 

Alapértelmezett indítás: letiltva 
A WebClient szolgáltatás szintén a Windows Server 
2003/XP operációs rendszerekben jelent meg először. A 
Win32 alkalmazások számára megengedhetővé teszi inter- 
netes és intranetes dokumentumok készítését, olvasását és 
írását. A szervizt a WebDAV (Web Distributed Authoring and 
Versioning) protokoll használja, ami pedig egy olyan állo- 
mánykezelő szolgáltatás, amely a HTTP (1.1) protokoll há- 
tán utazik, és gyakorlatilag teljes körű állománykezelési le- 
hetőségeket nyújt (beleértve a Drag and Drop-tól kezdve az 
állomány  megosztásig mindent). A WebDav Client 
Redirector szerviz segítségével pedig akár tűzfalakon és út- 
választókon keresztül is működik (persze engedélyez- 
ni/publikálni azért kell). Ha ki 
szeretnénk aknázni a WebDav előnyeit (bevett szokás sze- 
rint pl. az intraneten), vagy bizonyos szolgáltatások esetén 
az interneten is, akkor a klienseken feltétlenül futni kell en- 
nek a szerviznek (pl. Csoportházirendből is kötelezővé 
tehetjük, lásd előző szám), ellenkező esetben viszont in- 
kább hagyjuk meg letiltva, mert igencsak érzékeny terüle- 
ten dolgozik. 


Windows Image Acauisition 
(Wyindows Image Acauisiítion) 

A szerviz rövid neve: Stisvc 

Az alkalmazás neve: wiaservc.dil (svchost.exe) 

Függés: Remote Procedure Call, Shell Hardware 

Detection szervizek 

Függesztés: — 

Porthasználat: - 

Alapértelmezett indítás: letiltva 
Üzemeltetők számára valószínűleg nem túl érdekes szol- 
gáltatás a WIA, amely már a Windows Millenniumban is je- 
len volt (a Windows 2000-ben viszont nem). Kompakt 
megoldás, mert támogatja a SCSI, IEEE 1394 és az USB 
rendszerű képolvasókról és digitális fényképezőgépekről 
történő képolvasást. Gyakorlatilag elmondható, hogy alkal- 
mazás szolgáltatási szinten a WIA váltja fel a TWAIN rend- 
szert. A WIA a Windows Driver Model architektúra része és 
egyaránt jelent egy API-t az alkalmazások, valamint egy 
eszközvezérlő csatolófelületet az eszközök illesztőprog- 
ramjai részére. 
Igazából nem nagyon értem, hogy egy kiszolgáló számító- 
gépen mi haszna lehet ennek a szolgáltatásnak, minden- 
esetre annak ellenére, hogy valószínűleg biztonsági rizikót 
nem rejt a használata, hagyjuk meg az alapértelmezett 
tiltást. 
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WinHTTPRP Web Proxy 
Auto-Discovery Service 
(VMViINnHTTR automatikus 
webproxy-kereső szolgáltatás) 

A szerviz rövid neve: WinHttpAutoSvc 

Az alkalmazás neve: winhttp.dll (svchost.exe) 

Függés: DHCP Client szerviz, AFD Networking Support 

Environment, TCPAP Protocol Driver, IPSec Driver 

Függesztés: — 

Porthasználat: TCP 80 

Alapértelmezett indítás: kézi, elindítva 
Ez a szolgáltatás érdekesebb mint az átlag, így érdemes 
neki egy kicsit nagyobb teret szentelni. A feladata a hálózat- 
ban általában oly fontos proxy beállítások keresése és 
átadása a HTTP kliensek (például a böngészők) részére. 





Local Area Network (LAN) Settings 


Automatit cönfituratjon ——— E E EEEZEZEE ETI 


Automatic configuration may override manual settings. To ensure ! 
the use of manual settings, disable automatic configuration. 


7 fáutom: matically detect setting 


I Use automatic configuration script 
Árddress 
! 


"Proxy server ] 
T Use a proxy server for your LAN (These settings will not apply to ] 
] 


dial-up or VPN connections), 
Adta! 


Address; Íproxy.nbh.hu 
server for localjaddresses 


[7 Eypass proxy. 
BESE] 














Az automatikus proxy detektálás 


Ha pl. az Internet Explorerben bekattintjuk (vagy központi- 
lag a Csoportházirendben az egész tartományra kötelezően 
előírjuk) az ábrán is látható opciót (,Automatically detect 
settings"), akkor a szerviz elkezdi keresni a hálózaton a 
proxy információkat. 

De hogyan fogja megtalálni? Megmondja a DNS szerver! 
Ugyanis a DNS zónánkban manuálisan felvehetünk egy 
WPAD rekordot, CNAME típusként (pl. wpad.tjszki.hu), ami 
a proxy szerverre mutat, így egyszerűen kideríthető, hogy 
hova kell kapcsolódnia. 

Sőt, erre a feladatra a DHCP szerver is alkalmas, ti. a 252-es 
számú opció beállítása ugyanezt az eredményt hozhatja. Eh- 
hez először kattintsunk a DHCP konzolon a szerver nevére a 
jobb gombbal és válasszuk a , Set Predefined Option" menü- 
pontot. Ezután az Add... gombbal adjuk hozzá a paraméte- 
reket a következő képen látható végeredménnyel. Két lépés- 
ben történik meg majd mindez, hiszen először magát a 252 
számú bejegyzést kell felvennünk, majd azután azt az útvo- 
nalat megadni, amelyen a wpad.dat állomány jelen van. 

Így vagy úgy, de végül is lekerül a proxy információ a kliens- 
re és ettől kezdve pl. a böngésző az adott proxy kiszolgáló- 
hoz kapcsolódva mehet ki a netre (vagy nem ). 


Predefined Options and Values 





Option class: [DHEP StandardOptions 5] 
Option name: e sze 
sza sal Delete I 
Description: e info a klienseknekl 
Value 
String: 


http://ALFA:B80/vipad.dat 


A WPAD info hozzáadása a DHCP-ben 


Ennek a folyamatnak a sikerességéhez még az is szüksé- 
ges, hogy a proxy szerverünkön (jelen esetben az ISA 
Serveren) bepipáljuk a ,Publish automatic discovery infor- 
mation" opciót. 





ALFA Properties 


General ] Outgoing Web Reguests ] 
Incoming Web Reguests Auto Discovery] Performance ] Security ] 


ISA Server can provide configuration information to the client using Web 
Proxy Auto Discovery Protocol (WPAD). Use WPAD-supported facilities, 
such as DNS Server or DHCP Server. to publish ISA Server. 


[7 (Publish automatic discovery information! 


Use this port for automatic discovery reguests: 


za 


"To configure automatic discovery properties for clients, see Client 
Configuration in the console tree. 


AziSA-ban is engedjük meg... 


Ezen lehetőségek azonban csak a WinHTTP 5.1-es verzió- 
jának használata esetén állnak a rendelkezésünkre (a Win- 
dows 2000 SP3, Windows XP SP1 ill. a Windows Server 
2003 is tartalmazza). 

De mi ennek az egész folyamatnak, így a szerviz használa- 
tának is az előnye? Egy darab proxy szervernél az, hogy tel- 
jesen automatikus a proxy beállítás, ráadásul dinamikusan 
változhatnak a szerver adatai. Egy proxy tömb esetén (ha 
az ún. PAC azaz Proxy Auto-Configuration szkriptet elkészít- 
jük és a WPAD protokollal le is töltjük) azt is megtehetjük, 
hogy URL-től függően más és más proxy szerver felé irá- 
nyítjuk a kérést. 


Cikkünk következő részében 
Terveink szerint a Network Service fiók nevében futó szol- 
gáltatásokat mutatjuk be. 


GAL TAMÁS 
MCSE, MCSA, MVP 
gtamasatjszki.bu 


A cikkben szereplő URL-ek: 
(11. http;//tinyuri.com/ Zzs3e 
[2] http://tinyuricom/ 342tr 
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MVMIVRF-találkozó 
Amerikában 


ÚJDONSÁGOK A . NET FRAMEWORK 2.0-BAN 





Az MVP a Most Valuable Professional (legértékesebb szak- 
értő) rövidítése. Kik is vagyunk mi? Ugyanolyan átlagem- 
berek, mint Te, kedves olvasó. Azért kaptuk ezt a címet, 
mert évek óta sok embernek segítünk a levelezőlistákon és 
egyéb fórumokon abban, hogy eligazodjanak, és sikere- 
sen használják a Microsoft-technológiákat. Mi nem va- 
gyunk a Microsoft alkalmazottai. Ha azok lennénk, nem is 
kaphatnánk meg az MVP címet. Ez a , titulus" nem jelenti 
azt, hogy mi ,szupermenek" vagyunk, akik minden kérdés- 
re képesek válaszolni, és még az arcunk se lett ettől (sok- 
kal 0) nagyobb. Viszont a cím hozományaként sok olyan 
erőforráshoz jutunk és fogunk még hozzájutni, ami segít 
minket abban, hogy még jobban megértsük a Microsoft- 
technológiákat, és még több embernek tudjunk segíteni. 


Ilyen erőforrások többek között: 
Belső Microsoft kapcsolattartó, akin keresztül a leve- 
lezőlistákon felmerülő, számunkra megoldhatatlan 
problémához kérhetünk belső segítséget. Ez különö- 
sen akkor jön jól, ha például valami bug-gyanús, mert 
így nem futunk felesleges köröket egy ismert problé- 
ma miatt. 
Nem nyilvános MVP hírcsoportok. Ezek csak az MVP-k 
számára hozzáférhető csoportok, amelyeken mind a 
többi MVP-vel, mind a Microsoft dolgozóival tudunk 
kommunikálni. Mivel az MVP-k zöme nagyon jó a sa- 
ját szakterületén, itt nagyon értékes infókat tudunk 
összeszedni, amelyek egy részét a nyilvánossággal 
is megosztjuk (hacsak nem titoktartási szerződéssel 
védett tartalomról van szó). 
Knowledge Base (tudásbázis) cikkek, amelyek még 
nem jelentek meg, szerkesztés alatt állnak. 
A magyar MVP-k közül én például hozzáférhetek, il- 
letve publikálhatok a Whidbey buglistájához/ba 
(Visual Studio 2005 és .NET Framework 2.0). Azaz ha 
valami gyanús a Whidbey-jel kapcsolatban, akkor én 
leszek a gateway a bug adatbázis és a nyilvánosság 
között. Mellesleg az adatbázis előbb-utóbb nyilvános 
lesz, csak előbb rajtunk, MVP-ken tesztelik. 
Hozzáférhetünk, és , debugolhatjuk" egyes termékek 
forráskódját, például VS.NET, Windows stb. 





A lényeg tehát, hogy mi kívülálló emberek vagyunk, de hoz- 
záférünk egyes belső Microsoft-információkhoz annak ér- 
dekében, hogy hatékonyabban segíthessünk másoknak. 


Az MVP Summit egy, a világ különböző pontjairól érkezett 
MVP-k számára az Egyesült Államokban tartott szakmai 
rendezvény volt idén márciusban. A helyszín Seattle és 
Redmond. A rendezvény célja az MVP-k közötti nemzetkö- 
zi szintű kapcsolatépítés, valamint közvetlen visszacsato- 
lás a termékekről a Microsoft fejlesztőihez. 
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A redmondi konferencia-központ 


A rendezvény gerincét természetesen az előadások alkot- 
ták, ahol első kézből kaphattunk szakmai információkat. 
Ezekből szemezgetek a továbbiakban. Jövőbe néző infó- 
kat, amelyek a saját szűrőmön jöttek át, ennek megfelelően 
kéretik érdeklődve, de kritikusan olvasni. 








Longhorn Glass Effect 


A DataSet binárisan is képes lesz szerializálni magát, nem 
csak XML formátumban. Ez nemcsak azért érdekes, mert 
kevesebb sávszélességet fogyaszt az adatátvitel, hanem 
azért is, mert így sokkal kevesebb memóriát használnak 
mind generáláskor, mind feldolgozáskor, hisz nem kell ter- 
jedelmes XML-stringeket összeállítani. Az árnyoldal viszont 
az, hogy csak remoting esetén használhatjuk ki a bináris 
átvitelt,  vebszolgáltatások esetén nem. 





Seattle alulról 


A DataSet indexelését átírták, így sokkal gyorsabb lett. 
Miért, használ a DataSet indexet? Hogyan lehet rajta létre- 
hozni? Direktben sehogy, de amikor például Primary Keyt 
hozunk létre egy oszlopon, akkor keletkezik index az osz- 
lop adatain, hogy például a Find() metódus gyorsan tudjon 
keresni kulcs alapján. Vagy a DataView-k is használják az 
indexeket, automatikusan például a szűrt oszlopon. 
Gondolom, ismerős az a helyzet, hogy egyetlen táblát kel- 
lett volna kezelni, mégis DataSetet kellett használni, mert a 
DataTable nem tud sok dolgot, amit a DataSet igen. Ezt kor- 
rigálják a 2.0-ban, a DataTable mindent fog tudni, amit a 
DataSet, kivéve persze a több táblával kapcsolatos szol- 
gáltatásokat. 

Sok adat DataTable-be töltésére lesz egy Load metódus, 
ami valamilyen IDbDataReader tartalmát képes nagyon 
gyorsan betölteni a táblába. 








A DataView tartalmát lehet majd materializálni egy új 
DataView.ToTable() metódussal. Hasznos lehet, ha szűrt ki- 
menetet kell például hálózaton keresztülzavarni. 

Ami új és nekem meglepő volt, hogy az aszinkron SOL pa- 
rancsvégrehajtás (ez még nincs az 1.1-ben) nem használ 
ThreadPool szálakat. Azaz ha egyszerre 500 async pa- 
rancs is fut éppen akkor, nem fog 500 szálat allokálni az 
ADO.NET, így nem is fogja kimeríteni a ThreadPoolt. Az 
előadó szerint átírták a Managed Data Provider hálózatke- 
zelő részét, hogy ez így működhessen. 

E tudás ismeretében mutatott egy nagyon ravasz megol- 
dást, amivel extrém nagy terheltségű szerver esetén nagy 
áteresztőképességet lehet elérni. 





Látkép az egyik folyosó sarkában 


Az ötlet a következő. Írjunk egy aszinkron HttpHandlert. A 
handlerben az induló eseménynél elindítjuk az aszinkron 
SOL parancsvégrehajtást. Mivel az nem blokkol, az aszink- 
ron handler visszatér, így nem fogunk le ASP.NET-szálat 
sem a ThreadPoolból (ez a ThreadPool egy olyan állatfaj, 
aki nagyon hamar ki tud merülni). Mivel az ADO.NET se 
használ felesleges szálakat, a szerver minimális erőforrá- 
sokkal vár a parancsvégrehajtásra. 

Amikor az aszinkron SOL parancsvégrehajtás megtörténik, 
egy callback metódus visszaszól, ahol befejezzük a HTTP- 
válasz generálását. Nagyon szellemes megoldás, bár vá- 
rom magyarországi körülmények között azt a volumenű 
webes terhelést, ami miatt be kell vetni ezt a trükköt. 

Ami érdekes, hogy az SalConnection. Open()-nek viszont 
nem lesz aszinkron megfelelője, pedig még korábban így 
tervezték. Az ok az, hogy az SalConnection megnyitásakor 
lehet, hogy a kapcsolatot fel kell venni egy elosztott COM-- 
tranzakcióba. Ebben az esetben viszont nem tudják garan- 
tálni, hogy a BeginOpen() tényleg azonnal visszatérjen, 
azaz az aszinkron BeginOper() néha szinkron lenne. Ezért 
inkább nem lesz aszinkron. Érdekes dolog ez, hogy egyes 
problémákat még , házon belül" se egyszerű megoldani. 














Microsoft Fitness Vrails 


Ha egy redmondi kollégának tele van a feje 
a SOA-val, akkor mehet futni egy kört O 


A Strongly Typed DataAdapter szellemes lesz. Már a 2003. 
őszi PDC Buildben láttam, hogy a DataSet tervezőben nem 
csak a táblák vannak benne, hanem a táblákhoz kapcsoló- 
dó SOL parancsok is fel vannak véve. 
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Típusos DataSet és a hozzá kapcsolódó 
adapterek a VS.NET 2005-ben 


A Strongly Typed DataAdapter valami olyasmi lesz, hogy 
egy ST DataSetben a táblák szerkezete mellé a táblákat 
tápláló DataAdaptereket is felvehetjük a megfelelő SOL- 
parancsokkal vagy tárolt eljárásokkal együtt. Az adaptere- 
ket aztán némi kóddal meghajtják [Fill() hívások], így a vé- 
gén például STDataSet.GetAllCustomers() hívással fel is 
töltöttük a DataSetünk egy vagy több tábláját. 

Tetszőleges számú DataAdaptert hozhatunk így létre, pél- 
dául GetCustomerByld() stb. néven. 

Egy kis kódszösszenet az előbbi DataSet használatához: 


CustomersComponent c — new CustomersComponent( ( ) ; 

//Összes vásárló lekérése 

MainDataSet.CustomersDataTable customers 
c.GetAllCustomers ( ) ; 

//ID alapján egy vásárló lekérése 

MainDataSet. CustomersDataTable onCust — 
c . GetDataByID( "ALFKI") ; 











Azaz a Designer megírja az adatelérő réteg nagy részét (a 
CustomersComponentet is az generálta)! Kényelmesen le- 
het majd dolgozni a Table Modul Patternnel [2]. 

De mint tudjuk, az adatbázis alapú alkalmazások fejleszté- 
sére van egy másik út is, amely elsősorban a Java-világban 
terjedt el, ez az, amit Martin Fowler Domain Modellnek [3] 
hív. Ebben az esetben a klasszikus OOP tervezési elvek 
alapján üzleti objektumokat hozunk létre, amelyek általá- 
ban közönséges class-ok (osztályok). Például egy dolgo- 
zót modellezve lenne egy Employee osztályunk, amelynek 
egy példánya egy dolgozót reprezentál. Az adatokat, mint 
név, cím stb. tagváltozók tárolják. Az adott entitáson értel- 
mezett műveleteket szokásos OOP módon az objektum 
metódusaival implementáljuk. A modell előnye, hogy az 
adatok és a rajtuk értelmezett üzleti logika jól egybe van 
zárva, így könnyen kezelhető, módosítható modellt kapunk. 
Sokan nem tudnak róla, de már az 1.0-ban is lehetséges 
volt üzleti objektumokat databindolni WinForms vagy 
WebForms vezérlőkhöz. Például az előbbi Employee pél- 
dányokat egy ArrayListben tárolva simán meg lehet jele- 
níteni azokat egy DataGridben. Az oszlopok a publikus 
property-k tartalmát mutatják meg. 

A Whidbey VS.NET 2005-ben Design Time is működni fog 
a binding. Azaz a Data Access Layer által visszaadott 
Employee objektumot a Property Browserben hozzá lehet 
bindolni egy vezérlőhöz, és a GUI már mutatja is, milyen 
adatok vannak az entitásban. Úgy kell ezt elképzelni, 
ahogy most a grid működik Stronly Typed DataSetekkel, 
azaz már Design Time látszik, hogy fog kinézni a vezérlő. 


Zárszó 
Amiről itt most beszámoltam, az csak két előadás volt a ti- 
zenegynéhányból, amit láttam. A jövőben a TechNet ha- 
sábjain írok majd a 2.0-s .NET Framework várható újdonsá- 
gairól, a mostani cikknél sokkal mélyebb tartalommal. 
Érdekes volt a találkozó, és izgalmas volt megfigyelni, ho- 
gyan éli mindennapi életét egy másik kultúra. De hadd em- 
lítsek meg a sok szakmai élmény mellett egy igazán sze- 
mélyes örömöt is: egy hónapos kisfiam legjobb barátja az a 
rénszarvas lett, amit az MS Company Store-ban vettem. [4] 
SOCZÓ ZSOLT 
zsolt.soczoronetacademia. net 
ASP.NET MVP, MCSE, MCSD, MCSD.NET, MCDBA, MCI 
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A magyar MVP-k névsora 


a Balássy György, SharePoint Portal Server 
2 Gál Tamás, Windows Server Management 

na Máthé Zoltán, SOL Server 

a Moldova György, Office Systems 

a Pintér Szabolcs, NT Server 

m Soczó Zsolt, ASPNET 

2 Subicz Péter; Windows Server Directory Services 
2 Sztanya Ferenc, Terminal Server 


Elérhetőségeik [1]. 


Tippek S trükkök 


FÓKUSZBAN AZ SOL SERVER 2000 





Egy-egy trükk megismerése sokat segíthet 


a mindennapi munkában. Cikkünkben 


az SOLl 


Tábla sorainak egyetlen karakter- 
sorozattá fűzése 

Gyakran van szükség például oszloplisták különböző 
SELECT-ekben történő előállítására, begépelésére, esetleg 
dinamikus összeállítására, vagy éppen INSERT...SELECT 
kifejezésekben való megadására. Az ilyen jellegű feladat 
nem igényli kurzorok felhasználását. 


CREATE FUNCTION [dbo).([(ListStru)] (Eétable SYSNAME) 
RETURNS VARCHAR(8000) 
AS 
BEGIN 
DECLARE €stru VARCHAR (8000) 
SET Eéstru — "" 
SELECT €stru - €stru 4§ OUOTENAME(COLUMN NAME) - 
FROM INFORMATION SCHEMA . COLUMNS 
WHERE TABLE NAME - 
OBJECT NAME(OBJECT ID(Eetable)) 
ORDER BY ORDINAL POSITION 
LEOGSURŰ KSS 
SET E€stru - LEFT(€stru, DATALENGIH(€stru) - 2) 
RETURN E€stru 


END 

GO 

PRINT [dbo)].ListStru( " Shippers " ) 

Eredmény: [(ShipperID], [CompanyName]. [Phone] 


A fenti függvény (UDF — User Defined Function) kódja az 
INFORMATION. SCHEMA.COLUMNS view-ból válogat le 
sorokat (preferálni kell ezeket a view-kat a direkt rendszer- 
tábla-lekérdezésekkel szemben, mert ezek dokumentált 
struktúrája verzióról verzióra állandó). Minden sor esetén a 
COLUMN. NAME oszlopot a Östru változóhoz adja hozzá 
(kezdő értékkel kell ellátni, hogy ne legyen benne NULL ér- 
ték az összeadás miatt, valamint, hogyha a SELECT nem 
ad vissza egyetlen sort sem, akkor nem történik érték- 
adás). A OUJOTENAME() függvény használatával (a máso- 
dik paraméter elhagyása mellett) az oszlopneveket szögle- 
tes zárójelbe teszi, segítve ezzel a TSOL fenntartott szavak- 
ból összeállított oszlopnevekre való hivatkozást. Az 
OBJECT. NAME(OBJECT. ID()) hívás során az aktuális 
adatbázis minősített táblanevei esetén is jól működik a 
függvényünk, amely a végén az összeállított, vesszővel el- 
választott karakteres listával tér vissza. 


server 2000 használatához adurk tippeket. 


Ne használjuk az "sp " prefixet saját 
objektumneveinkhez 

Többször találkozom olyan saját készítésű objektumnevekkel 
(tárolt eljárások esetében), amelyek az SOL Server rendszer- 
szintű tárolt eljárásainak (SP — Stored Procedure) elnevezési 
konvencióit használják. Ez nem csak azért célszerűtlen, mert 
nem különülnek el a rendszer-SP-k, a saját készítésű SP-ktől, 
hanem azért is, mert az SOL Server motor az ilyen prefix-szel 
ellátott SP indításakor először a master adatbázisban keresi 
az eljárást. Teszi ezt azért is, mert ezek a rendszer-SP-k álta- 
lában bármely saját adatbázisból meghívhatóak, hiszen min- 
dig a master-ben keresi először a rendszer. Ha Profiler-rel 
nézzük a végrehajtást, jól látható, hogy gerjesztünk ezzel egy 
SP:CacheMiss eseményt is. Amennyiben elkövetjük ezt a 
prefix-elési hibát, könnyen készíthetünk olyan tárolt eljárást 
is, amelynek neve megegyezik egy master adatbázisban lé- 
vővel, ilyenkor a sajátunk soha nem fog meghívódni, ami per- 
sze hamar kiderül. Tehát használjunk prefixet bátran a saját 
SP-inkhez, de ne sp. " legyen. 


Használjunk tulajdonossal (owner) 
minősített objektumneveket 

Felesleges folyamatokat takarítunk meg azzal, ha az objek- 
tumneveinket minősítjük a tulajdonosával. Bizonyára ismert 
a TSOL objektumok hierarchikus elrendezése. Azaz egy 
tábla teljesen minősített neve (FON - Fully Oualified Name) 
a következő: 


ServerName . DatabaseName . OwnerName . TableName 
Pl.: ServerA.Northwind. dbo . Customers 


Az egyes minősítők közé pontot teszünk. A táblanév objektu- 
munk 3 minősítéssel rendelkezik, ezt a négyest nevezzük tel- 
jesen minősített névnek. Sőt, ugyan nincs feltüntetve, de a 
hierarchia tovább folytatható, például a táblához tartozó osz- 
lopnévre újabb ponttal kötve tudunk hivatkozni. A minősítés 
egyes szintjei (az objektum szintjéig) balról kiindulva teljesen 
elhagyhatók, illetve köztes szintek is kihagyhatók, ilyenkor két 
pont követi egymást. Amennyiben nincs megadva szerver- 
név, az aktuális szerver neve kerül behelyettesítésre, ha nincs 
adatbázis, az aktuális adatbázis neve. Ha a táblánk nevére 
tulajdonos nélkül hivatkozunk, a szerver először az aktuálisan 
bejelentkezett felhasználó által tulajdonolt objektumot keresi. 
Ha nem talál ilyet, akkor tovább keres dbo-val. Egy másik kis- 
kapu lehet, ha az adott felhasználó nevében elkészül egy ob- 
jektum, akkor nem az általunk feltételezett dbo tulajdonosú 
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objektumon dolgozik majd a rendszer, hanem az adott fel- 
használóval létrehozott objektummal. Tehát létrehozható 
végtelen számú azonos nevű és típusú objektum, ha külön- 
böző a tulajdonos. A másik indok, azok számára hasznos, 
akik gyakran választják az EXEC() helyett az sp. executesgl-t 
(nagyon helyesen) dinamikus lekérdezéseik végrehajtására. 
Mint ahogy a Books Online-ban (BOL) is olvasható, csak ak- 
kor kerül ismételt felhasználásra a végrehajtási terv, ha az ob- 
jektumnevek teljesen minősítettek (a Profiler-ben megfigyel- 
hető az SP:ExecContextHit esemény). A harmadik indok, 
amikor tárolt eljáráson belül nem használunk tulajdonost, 
nem az aktuális SP-t futtató felhasználó nevében fog futni a 
kódunk, hanem az SP-t létrehozó kerül behelyettesítésre 
az objektumokhoz a tulajdonos minősítéséhez. Végezetül 
mindezek még fontosabbak az objektumok létrehozásakor, 
hiszen az általunk minősítetlen tulajdonosú script-elt objektu- 
mok, amennyiben nem a megfelelő szerepű felhasználó fut- 
tatja, könnyen előfordulhat, hogy a dbo. TableName helyett 
egy UserName. TableName nevű jön majd létre. Az elkészített 
objektum struktúra fejlesztési környezetből az ügyfél környe- 
zetbe juttatásakor ezekre nagyon figyelni kell. A minősített 
nevek ezt a procedúrát egyértelművé teszik. 


Kód végrehajtása a szerver 

összes adatbázisára, illetve adott 
adatbázis összes táblájára 

Létezik a master adatbázisban két nem dokumentált eljá- 
rás rövid TSOL utasítások az összes adatbázison, valamint 
adott adatbázis összes tábláján történő végrehajtásra. 
Rendszert építeni ezen eljárásokra nem szabad, de a je- 
lenlegi SOL2000-es verzióban karbantartási célokra jó 
szolgálatot tehet olyan parancsok esetében, amelyek adott 
adatbázisra futnak csak le (/DBCC CHECKDB), vagy adott 
adatbázis adott táblájára (DBCC DBREINDEX), vagy akár 
SELECT utasítások is makrózhatók általa. 


EXEC sp MSforeachdb "SELECT !"?"" AS DBName, 
4 r FROM [?].dbo.sysusers" 

GO 

EXEC sp MSforeachdb "PRINT ""?"" DBCC CHECKDB 
zs 


EXEC sp MSforeachtable "SELECT ""?"" AS TABLENAME 
$ EXEC sp. helpindex ""?""" 

GO 

EXEC sp MSforeachtable "PRINT ""?"" 

4 DBCC DBREINDEX( " "?"")" 


Dátum műveletek 

Érdemes az igen költséges karakteres konverziók (CON- 
VERT(VARCHAR,..., style) helyett kihasználni a sokkal 
gyorsabb dátumkonverziós függvényeket: 


DECLARE €d DATETIME 
SET €d — "2004.02.10 10:15:30.100" 


1. példa: a fenti dátumhoz tartozó hónap első napjának 
meghatározása: 


SELECT DATEADD(month, DATEDIFF(month, O, €d), 0) 


Eredmény: 2004-02-01 00:00:00.000 


2. példa: a fenti dátumhoz tartozó hónap napjainak száma 
(szökőévekben is jól működik): 


SELECT DATEPART(DAY, DATEADD(DAY, -DATEPART(DAY, 
4 DATEADD(MONTH, 1, €d)), DATEADD(MONTH, 1, €d))) 


Eredmény: 29 


3. példa: a fenti dátumérték időkomponensének nullázása: 


SELECT DATEADD(day, DATEDIFF(day, O, €d), 0) 
Eredmény: 2004-02-10 00:00:00.000 


Rekordhalmazzal visszatérő 

tárolt eljárás adatainak további 
feldolgozása 

Gyakori eset, hogy információt szeretnénk kinyerni rendszer- 
szintű, illetve saját tárolt eljárásainkból, amelyek egy szá- 
munkra túl részletes vagy éppen nem elég részletes adathal- 
mazzal (SELECT) térnek vissza. Talán a legismertebb szin- 
taktika az INSERT...EXEC. Ilyenkor elkészítünk egy, a vissza- 
kapott rekordhalmaz struktúrájával megegyező üres tábla- 
struktúrát. Majd ebbe bele INSERT-áljuk az SP kimenetét. 


CREATE TABLE $Temp (spid SMALLINT, ecid SMALLINT, 
status NCHAR(30), loginname NVARCHAR(128) , 
hostname NCHAR(128), blk CHAR(5), 
dbname NVARCHAR(128), cmd NCHAR(16)) 

GO 

INSERT INTO fTemp EXEC sp who 


Igen ám, de elég körülményes kitalálni, vajon milyen adattí- 
pusú oszlopok képezik a visszakapott rekordhalmazt. Erre 
vagy van dokumentáció (BOL), vagy az SP olvasható tarta- 
lommal rendelkezik. Ennél egyszerűbb módszer az OPEN- 
OUERY(), OPENROWSET() függvények használata, ame- 
lyek kimenetét egy táblába irányítjuk, majd az INFORMA- 
TION. SCHEMA.COLUMNS view-ból akár le is kérdezhet- 
jük az oszlopok típusait, méreteit: 


SELECT t INTO Test 
FROM OPENGUERY (ServerName , "EXEC sp who ") AS a 
--FROM OPENROWSET( " SALOLEDB " , " ServerName ! ; 
--B; "UserName ! ; "Password!" , "EXEC sp who ") AS a 
GO 
SELECT COLUMN NAME, DATA TYPE, 
CHARACTER MAXIMUM LENGT 
FROM INFORMATION SCHEMA . COLUMNS 
WHERE TABLE NAME — "Test" 


MÁTHÉ ZOLTÁN 
matbezapbsi.bu 
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kimaradt... 


EXCHANGE 2000/ EXCHANGE SERVER 2003 - II. RÉSZ 


Az előző számunkban közölt cikk folytatásaként újabb 


Exchange-érdekességeket, tanulságokat ismertetünk. 


Z itt leírt témák — csakúgy, mint előző számunkban 

-— most sem kezdőknek szólnak! Akik nem értenek 

meg mindent, azoknak javasoljuk a 2400-as kód- 
jelű ,Implementing and Managing Microsoft Exchange Ser- 
ver 2003" tanfolyam elvégzését. Bátorítok minden kedves 
olvasót, hogy jelezzék e-mailben, ha valamiről további in- 
formációkat szeretnének, vagy csak egyszerűen írják meg 
véleményüket, ötleteiket, javaslataikat. 


Exchange fájlkiszolgálóként? 

Az alcímben feltett kérdés természetesen csak költői, nem 
javasolom, hogy az Exchange-et fájlkiszolgálóként hasz- 
nálja bárki is, de van néhány érdekes lehetőség, amit ki tu- 
dunk használni fájlok nyilvános mappákban történő tárolá- 
sakor. A nyilvános mappák egyik gyakori felhasználási te- 
rülete, hogy olyan Word- és Excel-állományokat tartalmazó 
üzeneteket tárolunk ott, amelyeket sok felhasználó olvas- 
hat. De vajon mindenki tudja-e, hogy közvetlenül is lehet 
publikálni Office-dokumentumokat nyilvános mappákba? 









Mall Recipient. 
Mall Regipient (for Review)... 

Mall Reciplent (as Attachment). .. 
41) Routing Recipient... 


Online Meeting Participant 
Recipient using a Eax Modem... 

Cal Recipient using Internet Fax Service... 

éli Microsoft Office PowerPoint 


A fenti ábrán a Word 2003 File menüjéből elérhető Send To 
23 Exchange Folder... parancsa látható, de ugyanez meg- 
van az Excel-ben is. Ha ide kattintunk, akkor kiválaszthatjuk 


Send To Exchange Folder 





Mi 
a Public Folders 
a CI Favorites A 
a CI AllPublic Folders 
CI Fájlszerver 
(CI Internet Newsgroups 
(CI Nonamett folderje 
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a megfelelő nyilvános mappát, amibe publikálni szeretnénk: 
A példa kedvéért hívjuk most ezt a mappát , Fájlszerver"- 
nek. Én mindjárt egy Word-dokumentumot és egy Excel- 
táblázatot is publikáltam ilyen módon ebbe a nyilvános 
mappába. Ha Outlookból megnézzük ennek az eredmé- 
nyét, a következőket láthatjuk: 


Fájlszerver 
örranged By: Date 


Newest on top TA 





I Today 
Administrator 
Book1 .xls 


Administrator 
Document1 doc 


13:36 wz 


13:34 g 


A publikáláskor sajnos nincs lehetőségünk megadni új állo- 
mányok esetében azok nevét, így a fenti ábrán az alaphely- 
zet szerinti nevek láthatók. Az azért biztató, hogy az 
Exchange , tudja", hogy ezek nem közönséges, , post" típu- 
sú bejegyzések, hanem egy Excel- és egy Word-állomány, 
amit az ikonokból is láthatunk. Hogyan lehetne más, ennél 
több információt látni ezekről az állományokról? Ha meg- 
nézzük az Excel-állományomat, akkor kiderül, hogy ez egy 
sematizált árajánlat, az egyszerűség kedvéért két fontos in- 
formációval: a címzett és a végösszeg egy-egy cellába van 
beírva. Nevezzük el ezeket a cellákat: az összeget tartalma- 
zót summa, a címzettet tartalmazót címzett névvel illettem. 
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Hasonlóan a Word-állományom is egy árajánlat, ahol szin- 
tén megtalálhatók ezek az információk, itt ezekhez summa 
és címzett nevű könyvjelzőket rendeltem: 


Árajánlat 


Címzett: ÍNepper és Tsa. Bt) 





Ezek után mindkét alkalmazásban felveszek egy Cégnév 
és egy Összeg nevű tartalomfüggő (Link to content) egye- 
di (Custom) tulajdonságot a File/Properties menüben, me- 
lyek rendre a címzett és a summa cellához/könyvjelzőhöz 
vannak kötve: 


Pra a áj agg lsi 


General 


Delete 


Date completed 





Department 
Destination 
Disposition 
Iype: 
Value: Euink to content 
Properties: ! Name value Type 
EDCégnév Rabló és Pa... Text 
EDÖSsszeg 987654 Number 


Ezek az egyedi tulajdonságok -— ugyanúgy, mint a 
SharePoint Portal Servernél — az úgynevezett ,property 
promotion" folyamat során Exchange Store-beli, felhaszná- 
ló által definiált (User-defined field) tulajdonsággá válnak, 
amelyeket meg lehet jeleníteni a mappa nézetében: 


[TATE Az eter tti 


LA AJ 


Maximum number of lines in multi-ine mode: [2.7] 
Select avallable fields from: 
User-defined fields ín folder 
Avallable fields: 








Show these fields in this order: 
Add -5 fImportance 
"con 
(áttadhmenk 


























Így a Fájlszerver nevű mappánk végleges Outlook-beli né- 
zetét akár a következő formátumúvá is át tudjuk alakítani: 












Fájlszerver 





Összeg [From ( Received 
123 456 Administrator 


ree 


1 Size 






Azaz ez egy olyan nézet, amelyben az állományokban ta- 
lálható információkat anélkül láthatom, hogy megnyitnám 
azokat: látom a cég nevét, amelynek az ajánlatot küldtem, 
illetve látom az ajánlat végösszegét is. Ha megnyitom az ál- 
lományokat, és módosítom ezeket az adatokat, akkor men- 
tés után természetesen ezek frissülnek az Outlook-nézet- 
ben is. 


Rendszerüzenetek átírása 

Az Exchange kiszolgálók sokfajta üzenetet küldenek a fel- 
használóknak. Azt, hogy hogyan lehet ezekre az üzenetek- 
re válaszolni, megnéztük az előző számban. Ezek az üze- 
netek a belső felhasználóknak olyan nyelven érkeznek, 
amilyen nyelvű a levelesládájuk. A nyelv olyan lesz, ami- 
lyen az először rácsatlakozó kliensgép területi beállítása. 
Előfordulhat, hogy nem tetszik nekünk a felhasználóknak 
küldött üzenetek megfogalmazása. Például a levelesláda 
méretének túllépésekor be lehetne tenni a figyelmeztető 
üzenetbe a megfelelő Help Desk-munkatársunk nevét és 
telefonszámát, mert nem mindenki ismeri az eredeti üze- 
netben emlegetett .pst állományok rejtelmeit, és önállóan 
nem tudna ilyet létrehozni. 

A Microsoft hivatalosan nem támogatja a rendszerüzenetek 
átírását, de megfelelő eszközzel és teszteléssel azért neki 
lehet veselkedni a feladatnak. Szerencsére az összes üze- 
net egy MDBSZ.DLL nevű erőforrás-dil-ben van összegyűjt- 
ve, így csak ezt kell módosítani. Ehhez eszköz található a 


ftp://ftp.microsoft.com/Softlib/MSLFILES/ 
RLTOOLS . EXE 


helyen. Ez egy önkicsomagoló állomány, ebben a szá- 
munkra érdekes segédprogram a RLOUIKED.EXE, mellyel 
nyelvenként lehet módosítani az üzeneteket. Számunkra a 
magyar és az angol nyelvű változat érdekes általában. 
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Fi ossary Edit ation 


Hely felszabadításához tör 


nem használt tételeket, vagy hívja a ri 
jel ztás 
Type: MESSAGE TABLE 


Name: 0 
10:13 


A New TextJsához törölje a nem használ tételeket, TETTHETETETEZTETEÁRTESEEETT vin 
Fj Current Text (Hely felszabadításához törölje a nem használt tételeket, vagy hívia a rendszergazdát K 


Mivel mondatonként szerepelnek a bejegyzések, és egy 
rendszerüzenet több mondatból is állhat, ezért nagyon ala- 
posan le kell tesztelni, hogy mit is írunk át, és az pontosan 
melyik rendszerüzenetben szerepel. Érdemes az eredeti 
dll-t elmenteni, hogy hiba esetén visszaállítható legyen. Az 
átírt üzenetek küldése az Exchange szolgáltatásainak új- 
raindítása után kezdődik. 

Ha javítócsomagot teszünk a kiszolgálónkra, akkor ez fe- 
lülíródhat, így a módosításokat érdemes dokumentálni, 
hogy újra elvégezhetők legyenek a változtatásaink. 
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Az Exchange kiszolgáló lassan áll le 
Ha az Exchange kiszolgálót tartományvezérlőre telepítjük — 
ami egyébként nem ajánlott, de például a Small Business 
Server esetében adottság -, akkor a szerver leállításánál 
tapasztalhatjuk, hogy az akár 10-15 percig is eltarthat. En- 
nek oka, hogy a szolgáltatások leállásának sorrendje nem 
ideális, azaz a Local Security Authority Subsystem szolgál- 
tatás (ezen belül fut az AD) viszonylag gyorsan leáll, míg az 
Exchange különböző szolgáltatásai lassabban, és mire né- 
melyik, AD-t intenzíven használó Exchange-szolgáltatás 
leállna, addigra time-out várakozási állapotba kerülnek az 
AD elérhetetlensége miatt. 

Megoldás, hogy készítünk egy leállító parancsfájlt, például: 


net stop MSExchangeMGMT /yes 
net stop RESvc /yes 

net stop POP3Svc /yes 

net stop IMAP4ASvc /yes 

net stop NntpSvc /yes 

net stop SMTPSVC /yes 

net stop MSExchangeES /yes 
net stop MSExchangelS /yes 
net stop MSExchangeMTA /yes 
:net stop MSExchangeSA /yes 


Természetesen a ténylegesen futó szolgáltatásainkat figye- 
lembe véve kell ezt kialakítani. A legjobb, ha ezt a fájlt be- 
tesszük az Excange/DC gépünk Shut down scriptjébe, így 
biztos, hogy nem fogjuk elfelejteni futtatni leállítás előtt. Er- 
re a Group Policy-t tudjuk felhasználni: 
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ExchangeshutDown (virtw2k3.igib c 
A í Computer Configuration Scíptz 
(I Software Settings 
(I Windows Settings 

z) Scripts (Startupjshutdor 
Securty Settngs 

(a (I Administrative Templates 
E ff User Configuration 
(CI Software Settings 
B CI Windows Settings 
(3 CT Administrative Templates 









Shutdown Sciipts for ExchangeShutD om 











Parametett 


ELTETT Aaa 








Script Name: 
ee 


Script Parameters: 


eses 
OK Cancel 





Exchange rendszergazda-jogosult- 
ságok finomhangolása 

Az Exchange ,beépítetten" háromfajta rendszergazdai 
szerepet kínál fel az Exchange System Manager Delegati- 
on Wizardt-jával: 


[ET edig ge] £ 


(Group (recommended) or User: 


Role: 


I Exchange View Only Administrator sz ] 


Exchange Administrator 








Ez erős leegyszerűsítése a világnak, önmagában csak ezek- 
kel nem nagyon tudjuk megadni például annak a rendszer- 
gazdának a jogosultságait, aki csak a nyilvános mappákért 
felel, vagy azét sem, aki csak a Routing Group-ok kialakítá- 
sáért és a connector objektumok konfigurálásáért felel. Elvi- 
leg belemászhatnánk az AD-be, és adhatnánk jogosultságo- 
kat csak bizonyos objektumtípusokra is, de ez elég munka- 
igényes, és nehezen átlátható eredményhez vezetne. Az 
egyszerűbb megoldás, hogy kihasználjuk az Administrative 
Group-ok lehetőségeit, és minden Exchange objektumot, 
amit csak lehet, szétpakolunk külön AG-kbe. Az alábbi ábra 
egy ilyen szétcincált állapotot mutat: 








A 3 1038 Org (Exchange) 
(a Global Settings 
(Ca Recipients 
a ta 















2.40 Folder Admin Group 

9-2 Folders 

a Routing Group Admin Group 
CA Routing Groups 

a a Policy Admin Group 

(a System Policies 


























Létrehoztam az egyes AG-objektumokat, majd bennük az 
üres Folders, Routing Groups, System Policies konténere- 
ket. De vajon hogyan kerülnek át ide az eredeti helyükről a 
mappák, routing goup-ok stb.? Nagyon egyszerű: Cut- 
Copy eljárással! Az Exchange System Manager rendelke- 
zik ezzel a szövegszerkesztőkben megszokott képessé- 
gekkel, ki tudjuk vágni az egyik objektumhierarchiát, és be 
tudjuk illeszteni az új helyére. A régi, üres tároló objektumo- 
kat ki tudjuk törölni. Ezek után már az új AG-kre kell a meg- 
felelő rendszergazdai szerepeket kiosztani a szegényes kí- 
nálatból, de ez pont az eredetileg elgondolt, objektumti- 
pusra szelektált jogosultságot fogja eredményezni. Termé- 
szetesen ezt csak natív módú Exchange szervezetben tud- 
juk megtenni. 


sApróságok" 

Úgy tapasztaltam, hogy néhány Exchange-beállítási lehe- 
tőség értelmezése sok rendszergazdának gondot okoz, 
mert nem teljesen egyértelmű a beállítás melletti felirat, és 
a súgó sem. Például a nyilvános mappák adatbázisainak 
Replication tulajdonságlapján van egy , Replication messa- 
ge size limit (KB)" nevű attribútum: 


Public Folder Store (VIRTW2K3) Properties i xx 








FulkTextindexing — ] — Detais ] — Policies ] Security ! 
General] Database Replicatiin —] Limíts 
Beplication intervak: En 

Limits: - 

Rieplication interval for always (minutes): 

Replication message size limit (KB): ih 


Restore Defaults ] 
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Az ember azt hinné, hogy ezzel be lehet állítani, hogy mek- 
kora legyen az a maximális méretű üzenet, amelyet a rend- 
szerünk még hajlandó lesz replikálni. 

A súgó sem ad igazán jó eligazítást, idézem: 





B Replicatian message size limit (KB) 





Use this text box to specify a value for 
replication-message size lirnit. 





A valóságban ezzel a paraméterrel azt lehet szabályozni, 
hogy lehetőleg mekkora legyen a legkisebb replikációs 
üzenet. Azaz, ha több pici üzenetet kellene replikálni egy 
replikációs ciklus során, akkor az Exchange inkább össze- 
fogja ezeket egy nagyobb üzenetbe, és úgy küldi el a töb- 
bi kiszolgálónknak. Ez az érték alaphelyzetben 300 KB, de 
itt módosítani lehet ezt. 

A másik félreértésre okot adó beállítási lehetőség a 
Recipient Policy-knál található: 


CETTEETYTZETTTTT YE EKENE NN NETETE ETETETT 2. 
General. E-Mailáddresses (Policy) ] Detaits ] 


Generation rules: 
Type 












Address 


SMTP iaib.dom 
(T smtp (önoname.bt 
EKTEZYSETZETETT TT 
General ] 
A SMTP Address 
Type: 
Address: 


[Eroname. bt 


( This Exchange Organization is responsible for all mail delivery to this 


Az előbbi képen a hátrébb található ablakba felvettem egy 
, (Ononame.bt" címzési sémát a generálási szabályok közé, 
de nem tettem pipát az előtte található kis négyzetbe. Ek- 
kor, ha megnyitjuk ennek a címnek a tulajdonságlapját, ak- 
kor alul a pipa a ,This Exchange...." felirat mellett határo- 
zottan ott van. Azt hihetnénk, hogy attól még, hogy automa- 
tikusan nem generáltatjuk le a mailboxaink számára a , non- 
ame.bt" végű e-mail címeket, az Excange-szervezetünk be 
fogja fogadni a noname.bt-nek küldött leveleket. Az igaz- 
ság az, hogy sajnos ennek ellenére az Exchange-ünk relay- 
nek fogja értelmezni ezeket a próbálkozásokat. Azaz csak 
akkor érzi sajátjának a noname.bt-nek küldött leveleket, ha 
mindkét pipa be van rakva. 

Mit tegyünk akkor, ha nem akarjuk automatikusan generál- 
tatni egy új e-mail címet a felhasználóknak, mert manuáli- 
san akarjuk ezeket kialakítani, de mégis szeretnénk, ha az 
Exchange elfogadná az ilyen címekre küldött leveleket? 
Ennek egyik módja, hogy külön Recipient Policy-ban defi- 
niáljuk ezt az új e-mail címet, és olyan szűrőfeltételt adunk 
meg, amely garantáltan üres halmazt eredményez. 

Végül nézzük a globális beállítások között található 
, Sender Filtering" szűrőfeltétel egyik beállítását: 


TT árchivefiltered messages 
TT Filter messages with blank sender 
[7 Drop connection if address matches filter 


Archiválásról beszél, de vajon hova archivál? A súgó szin- 
tén nem sokat segít. A válasz az, hogy az archiválás helye 
az SMTP virtuális szerverek munkakönyvtáraiban létrejövő 
filter" könyvtár lesz: 


cexchange telepítési 
partíció:VexchsrvrWnailrootNsvsitoNfilter 
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A hivatalos Microsoft tanfolyamok mellett kínált egyedi tanfolyamaink: 


IOSOFT- John Bryce 
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9 Rendszerbevezetési ismeretek (módszertan és gyakorlat) — 3 nap 
2 Exchange Server 2003 rendszergazda ismeretek Exchange 2000 Cim 


rendszergazdáknak — 2 nap 
3 Visual Basic.NET Masters" Track: haladóknak — 5 nap 


Tanfolyamok az ország egész területén! 
Mobil oktatólaborunkkal bárhol megtartjuk tanfolyamainkat. 


IOSOFT-JOHN BRYCE 
OKTATÓKÖZPONT KFT. 
judi c 8 
Web: vm 
Telefon: 2 
E-mail: 


(A mobil oktatólabor felállítását a Foglalkoztatáspolitikai és Munkaügyi Minisztérium támogatta.) 


Microsoft SA oktatási kuponok beválthatók 


Nálunk beválthatja a Microsoft Software Assurance licenc vásárlása után kapott 
oktatási kuponjait! Minden kupon 1 ingyenes tanfolyami napot jelent. 


Ha nem tudja, hogy mi ez a kupon, hívja munkatársainkat! 





Aszurance 


Microsoft ) 


CERTIFIED ) Learning Solutions 


vízsgák és minősítések 


MICROSOFT OKTATÁSI TÁJÉKOZTATÓ 


A Microsoft kínálatában több mint negyven féle technikai 


vizsga van, amelyeket a hivatalos Microsoft 


oktatóközpontokban lehet letenni. Összeállításunkban 


részletesen ismertetjük a Microsoft vizsgák 


és minősítések rendszerét. 


minősítések megszerzéséhez a Microsoft által 

előírt úgynevezett kötelező (vagy fő, angolul core) 

és szabadon választható (vagy kiegészítő, ango- 
lul elective) vizsgákat kell teljesíteni. Az egyes minősítések 
többféle vizsgaösszeállítással is megszerezhetőek. A Win- 
dows Server 2003 és a Visual Studio .NET megjelenésével 
a vizsgák száma, valamint az adott minősítések követel- 
ményrendszere is megváltozott illetve bővült. 


Microsoft termékspecialista (MCP) 

Követelmény: a cím elnyeréséhez egy vizsgát kell letenni 
bármely aktuális Microsoft vizsga közül. Ez tulajdonképpen 
a bevezető minősítés, erre építve szerezhet magasabb fo- 
kozatokat további vizsgák letételével. 


Microsoft Windows 2000 rendszer-adminisztrátor 
(MCSA on Windows 2000) 

Követelmény: a cím elnyeréséhez 3 kötelező és 1 szaba- 
don választható vizsgát kell letenni. 

Kötelező vizsgák: 070-210, vagy 070-270, 070-215, 
070-218 

Választható vizsgák: 070-028, 070-0O86, 070-214, 070-216, 
070-224, 070-227 , 070-228, 070-244. Választható vizsgák 
lehetnek még a CompTIA A-t és Network-- vizsgái is. 


Microsoft Windows 2000 rendszer-adminisztrátor 
F biztonság (MCSA 7 Security) 

Követelmény: a cím elnyeréséhez 3 kötelező és 2 speciális, 
biztonság témájú vizsgát kell letenni. 

Kötelező vizsgák: 070-210, vagy 070-270, 070-215, 
070-218 

Speciális vizsgák: a 070-214 és a 070-227, vagy 

a CompTIA Security-- vizsgája. 


Microsoft Windows 2000 rendszer-adminisztrátor 
t Messaging (MCSA £ Messaging) 

Követelmény: a cím elnyeréséhez 3 kötelező és 1 speciális 
vizsgát kell letenni. 

Kötelező vizsgák: 070-210 vagy 070-270, 070-215, 
070-218 

Speciális vizsgák: 070-224 vagy 070-284 


tt 


Microsoft Windows 2003 rendszer-adminisztrátor 
(MCSA on Windows 2003) 

Követelmény: a cím elnyeréséhez 3 kötelező és 1 szabadon 
választható vizsgát kell letenni. A korábbi Windows 2000 ala- 
pú MCSA minősítéssel rendelkezők a 070-292-es kódú vizs- 
ga letételével frissíthetik minősítésüket MCSA 2003-ra. 
Kötelező vizsgák: 070-210, vagy 070-270, 070-290, 
070-291 

Választható vizsgák: 070-O86, 070-227 , 070-228, 070-284, 
070-299. Választható vizsgák lehetnek még a CompTIA 
A-4-, Network-- vagy Server-t- vizsgái is. 


Microsoft Windows 2000 rendszer-adminisztrátor 
t Messaging (MCSA 1 Messaging) 

Követelmény: a cím elnyeréséhez 3 kötelező és 1 speciális 
vizsgát kell letenni. 

Kötelező vizsgák: 070-210 vagy 070-270, 070-290, 
070-291 

Speciális vizsgák: 070-284 


Microsoft Windows 2000 rendszermérnök 
(MCSE on Windows 2000) 

Követelmény: a cím elnyeréséhez 5 kötelező és 2 szaba- 
don választható vizsgát kell letenni. 

Figyelem! A 070-019, 070-028, 070-029 vizsgák 2004. 
júniusától megszűnnek! 

Kötelező vizsgák: 070-210, vagy 070-270, 070-215, 070- 
216, 070-217 és a 070-219, 070-220, 70-221, 070-226 kö- 
zül az egyik. 

Választható vizsgák: 070-019, 070-028, 070-029, 070-O86, 
070-214, 070-218, 070-219, 070-220, 070-221, 070-224, 
070-225, 070-226, 070-227, 070-228, 070-229, 070-230, 
070-231, 070-232, 070-234, 070-244, amennyiben az nem 
szerepelt a kötelezőek között. Az azonos témakörű, de kü- 
lönböző verziójú termékhez kapcsolódó vizsgákat egyként 
tekinti a Microsoft. 


Microsoft Windows 2000 rendszermérnök - 
Messaging (MCSE - Messaging) 

Követelmény: a cím elnyeréséhez 5 kötelező és 2 speciális 
vizsgát kell letenni. 

Kötelező vizsgák: 070-210 vagy 070-270, 070-215, 070- 
216, 070-217 és a 070-219, -220, -221, -226 közül az egyik. 
Speciális vizsgák: a 070-224 és a 070-225 
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Microsoft Windows 2003 rendszermérnök 
(MCSE on Windows 2003) 

Követelmény: a cím elnyeréséhez 6 kötelező és 1 szaba- 
don választható vizsgát kell letenni. A korábbi Windows 
2000 alapú MCSE minősítéssel rendelkezők a 070-292-es 
és 070-296-os kódú vizsga letételével frissíthetik minősíté- 
süket MCSE 2003-ra, mellyel automatikusan a MCSA 2003 
címet is elnyerik. 

Kötelező vizsgák: 070-210, vagy 070-270, 070-290, 
070-291, 070-293, 070-294, és a 070-297 és 070-298 kö- 
zül az egyik. 

Választható vizsgák: 070-086, 070-227, 070-228, 070-229, 
070-232, 070-284, 070-297, 070-298, 070-299 közül az 
egyik, amennyiben az nem szerepelt a kötelezőek között. 


Microsoft Windows 2003 rendszermérnök 
Messaging (MCSE zoo3ztMessaging) 

Követelmény: a cím elnyeréséhez 6 kötelező és 2 speciális 
vizsgát kell letenni. 

Kötelező vizsgák: 070-210 vagy 070-270, 070-290, 
070-291, 070-293 és a 070-297, -298 közül az egyik. 
Speciális vizsgák: 070-284 és a 070-285 


Microsoft adatbázis-adminisztrátor 

(MCDBA) 

Követelmény: a cím elnyeréséhez 3 kötelező és 1 szaba- 
don választható vizsgát kell letenni. 

Figyelem! A 070-015, 070-019, 070-175 vizsgák 2004 
júniusától megszűnnek! 

Kötelező vizsgák: 070-215, 070-228, 070-229 

Választható vizsgák: 070-216, 070-015, 070-0O19, 070-175, 
070-305, — 070-306, — 070-315,  070-316,  070-310, 
070-320. 


Microsoft alkalmazásfejlesztő 

(MCAD) 

Követelmény: a cím elnyeréséhez 2 kötelező és 1 szaba- 
don választható vizsgát kell letenni. 

Kötelező vizsgák: a 070-305, 070-306, 070-315 és 070-316 
közül az egyik és a 070-310, vagy 070-320 közül az egyik. 
Választható vizsgák: 070-229, 070-230, 070-234 vagy a 
070-305, 070-306, 070-315, 070-316 közül az egyik, 
amennyiben az nem szerepelt a kötelező vizsgák között. 


Microsoft fejlesztőmérnök 

(MCSD on Visual Studio 6) 

Követelmény: a cím elnyeréséhez 3 kötelező és 1 szaba- 
don választható vizsgát kell letenni. 

Figyelem! A címhez kapcsolódó vizsgák a 070-229, 
070-230 és 070-234 kivételével 2004 júniusától meg- 
szűnnek! 

Kötelező vizsgák: 070-100, a 070-016 és 070-176 közül az 
egyik és a 070-015 és 070-175 közül az egyik. 
Választható vizsgák: 070-015, 070-016, 070-019, 070-029, 
070-152, 070-175, 070-176, 070-229, 070-230, 070-234 
közül az egyik, amennyiben az nem szerepelt a kötelező 
vizsgák között. 


Microsoft fejlesztőmérnök 

(MCSD on Visual Studio .NET) 

Követelmény: a cím elnyeréséhez 4 kötelező és 1 szaba- 
don választható vizsgát kell letenni. 

Kötelező vizsgák: 070-300, a 070-305, 070-306 közül az 
egyik, a 070-315, 070-316 közül az egyik, valamint a 070- 
010, 070-320 közül az egyik. 

Választható vizsgák: 070-229, 070-230, 070-234 


Felkészülési lehetőségek 

a vizsgákra 

Az egyes vizsgákra való felkészüléshez egyéni és csopor- 
tos képzési megoldásokat kínál a Microsoft. 


Hivatalos Microsoft oktatóközpontok 
(MSCTEC) és bivatalos Microsoft tanfolyamok 
Az anyag elsajátításának és a vizsgára való felkészülésnek 
a leghatékonyabb módját a hivatalos Microsoft oktatóköz- 
pontokban (Microsoft CTEC) tartott, tapasztalt, minősített 
Microsoft tréner (MCT) oktató szakemberek által vezetett 
csoportos tanfolyamok és konzultációk jelentik. Az intenzív 
kurzusok során az elméleti anyagot folyamatos gyakorlatok 
és laborok egészítik ki. 


Hivatalos Akadémiai Tréningprogram (Microsoft 
IT Academy Program) 

főiskolai, egyetemi oktatási intézményekben, adott hivata- 
los Microsoft tanfolyami oktatások keretén belül szintén le- 
hetőség van hivatalos Microsoft tanfolyamok hallgatására. 


Microsoft Press kiadványok 

A legelterjedtebb, legnépszerűbb szakkönyvek az elméleti 
anyag elsajátításához és a vizsgára való felkészüléshez. A 
Microsoft Press kiadványai elsősorban önálló tanulásra 
szánt tréningcsomagok, szakkönyvek, melyek különböző 
témakörökben, különböző felkészültségű szakemberek ré- 
szére elméleti és gyakorlati anyagokat, feladatokat, ellenőr- 
ző kérdéseket és CD-mellékleten hasznos információkat, 
teszteket, segédprogramokat is tartalmaznak. 


Online források 

Számos vizsgafelkészítő könyv és próbateszt is megvásá- 
rolható, vagy letölthető a Microsoft és más cégek webolda- 
lairól is az egyes tesztekhez, melyek segítségével felmér- 
heti jelenlegi tudását, és azt, hogy melyek azok a témakö- 
rök, melyekben csiszolnia kell még ismereteit. A Microsoft 
Solution Developer Network (http://msdn.microsoft.com), 
valamint a Technet (http://technet.microsoft.com) oldalán 
első kézből származó információhoz juthat a Microsoft va- 
lamennyi termékével és technológiájával kapcsolatban. 


Hivatalos Microsoft tananyagok (Microsoft 
official Curriculum, MOC) 

Különböző témakörökben, különböző felkészültségű szak- 
emberek részére, elméleti és gyakorlati anyagokat, felada- 
tokat, ellenőrző kérdéseket és CD-mellékleten hasznos in- 
formációkat, teszteket tartalmazó hivatalos kiadványok. 
(Ezek Microsoft partnerek vagy trénerek által, vagy hivata- 
los Microsoft tanfolyamokon érhetők el.) 
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Kapcsolódó 

Kód A vizsga tárgya tanfolyamok 
pdcisT Ti 

070-O15 — Designing and Implementing Distributed Applications with MS Visual C---- 6.0 
070-O16 — Designing and Implementing Desktop Applications with MS Visual C--- 6.0 
070-O19  Designing and Implementing Data Warehouses with Microsoft SAL Server 7.O 
070-O2B —Administering Microsoft SOL Server 7.0 
070-O29 — Designing and Implementing Databases with Microsoft SOL Server 7.0 
070-OB1  Implementing and Supporting Microsoft Exchange Server 5.5 
070-OBB  Implementing and Supporting Microsoft System Management Server 2.0 827828 
070-100  Analyzing Reguirements and Defining Solutions Architectures 
070-152 — Designing and Implementing Web Solutions with Microsoft Visual InterDev 6.0 1017 
070-175 — Designing and Implementing Distributed Applications with Microsoft Visual Basic 6.0 1016 
070-176 — Designing and Implementing Desktop Applications with Microsoft Visual Basic 6.0 1013 
070-210  Installing and Configuring and Administering VVindows 2000 Professional 2152/1560 
070-214 — implementing and Administering Security in Windows 2000 Environment 2150/2153 
070-215  Installing and Configuring and Administering Microsoft Windows 2000 Server 2152/1560 
070-216 — Implementing and Administering Microsoft Windows 2000 Network Infrastructures 2153/1560 
070-217 — Implementing and Administering Microsoft Windows 2000 Directory Services Inírastructures 2154/1560 
070-218  Managing a Microsoft Windows 2000 Network Environment 2126 
070-219 — Designing Microsoft Windows 2000 Directory Services Infrastructure 1561 
070-220  Designing a Secure Microsoft Windows 2000 Network 2150 
070-221 — Designing Microsoft Windows 2000 Network Services Infrastructure 562 
070-222 — Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 2010 
070-223  Installing, Configuring, Administering Microsoft Windows 2000 Clustering Services 2087 
070-224  Installing, Configuring, Administering Microsoft Exchange 2000 Server 1572 
070-225  Designing and Deploying a Messaging Infrastructure with Microsoft Exchange Server 2000 1573,2355 
070-e226  Designing Highly Available Web Solutions with Microsoft Windows 2000 Server 2088 
070-227  Installing, Configuring, Administering Microsoft ISA Server 2000 Enterprise Edition 2159 
070-228  Installing, Configuring, Administering Microsoft SOL Server 2000 Enterprise Edition 2072 
070-e2e2e9  Designing and Implementing Databases with Microsoft SOL Server 2000 Enterprise Edition 2073 
070-230 — Designing and Implementing Solutions with Microsoft BizTalk Server 2000 Enterprise Edition 2379 
070-e2e32 — Designing Highly Available Web Solutions with Microsoft Windows 2000 and Application Center 2203 
070-e2e34 — Designing and Implementing Solutions with Microsoft Cornmerce Server 2000 2185 
070-244 — Supporting and Maintaning Microsoft Windows NT 4.0 Server Network 
070-270  Installing, Configuring, and Administering Microsoft Windows XP Professional 2272 
070-284 — Implementing and Managing Microsoft Exchange Server 2003 2400 
070-29g0 — Implementing, Managing and Maintaining a Microsoft Windows Server 2003 Environment 2273, 2274, 2275 
070-291 — Implementing, Managing and Maintaining a Microsoft Windows Server 2003 Network 2276, 2277, 2208 
070-29ge — Upgrading System Administrators Skills from Windows 2000 to Windows Server 2003 2209 
070-293 — Planning, Implementing and Maintaining a Microsoft Windows Server 2003 Network Infrastructure 2278 
070-eg4 — Planning, implementing and Maintaining a Microsoft Windows Server 2003 Active Directory 2279 
070-296  Upgrade System Engineers Skills frorn Windows 2000 to Windows Server 2003 2210 
070-297 — Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure 2282 
070-298 — Designing Security for a Microsoft Windows Server 2003 Network 830 
070-29g9  Implementing and Administering Security in a Microsoft Windows Server 2003 Network előkészületben 
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070-300  Analyzing Reguirements and Defining Solutions Architectures in Microsoft .NET 
070-305  Developing Web Applications with Microsoft Visual Basic .NET and Visual Studio .NET 
070-306  Developing Windows Applications with Microsoft Visual Basic .NET and Visual Studio .NET 
070-310  Developing Web Services and Server Components with Microsoft Visual Basic .NET 
070-315  Developing Web Applications with Microsoft Visual Cs .NET and Visual Studio .NET 
070-316 Developing Windows Applications with Microsoft Visual Ct .NET and Visual Studio .NET 
070-320 — Developing Web Services and Server Components with Microsoft Visual Cit .NET 


2710 
2373, 2310, 2389, 2415 
2373, 2565, 2389, 2350 
2524, 2557, 2389 
2124, 2310, 2389, 2349 
2349, 2555, 2389, 2350 
2524, 2557, 2389 





Figyelem! A szürkével jelzett vizsgák 2004-ben megszűnnek! A részleteket lásd a Microsoft weblapján! 





Microsoft információs CD-k (TecbNet, MSDN) 
Általában havonta megjelenő információs CD-csomagok, 
melyek a legkülönbözőbb témákban és termékekhez kap- 
csolódva tartalmaznak támogatási információt, tudnivalót, 
valamint a legújabb termékeket, szervizcsomagokat és ter- 
mékbétákat. 


Vizsgaközpontok 

A Microsoft vizsgákat az  oktatóközpontok hivatalos 
Promertric valamint Pearson VUE vizsgaközpontjaiban tehe- 
ti le, ahol szabályozott és szigorú követelményrendszernek 
megfelelő körülmények között vizsgázhat. A vizsgakérdése- 
ket a Microsoft állítja össze, tehát azok összetétele, paramé- 
terei mindkét vizsgaközpont esetében azonosak. A vizsgák 
során a vizsgaközpont rendjét be kell tartani és szabályza- 
tát el kell fogadni. A vizsgákra az egyes vizsgaközpontok 
adminisztrátorainál, vizsgaszervezőinél lehet regisztrálni. 
Ezen kívül lehetőség van online regisztrációra is a Prometric 
vagy a VUE weboldalán keresztül is a világ bármely köz- 
pontjába, de fontos, hogy ezen esetekben is értesítsék az 
adott központot. Általános szabály, hogy vizsgázási szán- 
dékát, vagy annak lemondását, áttételét 48 órával a vizsga 
előtt jelezze. Szintén fontos, hogy a vizsgaközponttól kapott 
vizsgázó azonosítót ne hagyja el, mert minden vizsgaered- 
ménye és adata ezen számhoz lesz/van társítva, és jelent- 
kezésnél erre szüksége van (a vizsgajelentkezési lapon fel 
kell tüntetni, vagy online jelentkezésnél kell megadni). 


A minősítések karbantartása 

A vizsga letételét követően annak végeredményét azonnal 
megtudhatja, és erről a vizsgaközpont által aláírt és lepe- 
csételt okmányt kap. Az első sikeres vizsga esetén, vagyis 
a Microsoft termékspecialista (MCP) minősítés megszerzé- 
sekor e-mailben kapja meg a Microsoft Certified 
Professional azonosítószámát (MCP ID), valamint egy jel- 
szót, melynek segítségével az MCP-sek számára fenntar- 
tott privát weboldalra jelentkezhet fel, illetve készíthet pass- 
port-ot. Éppen ezért nagyon fontos, hogy mindig aktív és 
aktuális e-mail címmel rendelkezzen, mert ezt és az MCP 
ID-t elsődleges azonosítónak tekinti a Microsoft az ügyinté- 
zések során. (Figyelem! Az MCP ID nem mindig egyezik 
meg a vizsgaközpontnál kapott azonosítóval!). 

Amennyiben a vizsga letételével egyetemben először egy 
minősítést is elnyert, akkor a Microsoft az ehhez kapcsoló- 
dó okmányokat (oklevél) és kiegészítőket egy csomagocs- 
ka, ún. Welcome Kit formájában postai úton juttatja el a 
vizsgázó részére, a jelentkezési lapon megadott címre, kö- 





rülbelül a vizsgát követő egy hónapon belül. Minden adatát 
lehetősége van módosítani és karbantartani az MCP-sek 
privát weboldalán a Microsoft adatbázisában. Ugyanott le- 
hetősége van megtekinteni és kinyomtatni eddig letett vizs- 
gáit és minősítéseit (transcript). Ez igen fontos dokumen- 
tum, hiszen ez tartalmazza az aktuális státuszát és vizsgáit, 
vagyis az oklevelekkel együtt ez a dokumentum igazolja 
minősítését és annak érvényességét. 

A vizsgák természetesen nem örök életűek, vagyis az új 
szoftververziók, termékek megjelenésével azok frissítése 
szükséges. Ezeknek az időpontjait és lejáratait a Microsoft 
határozza meg, és erről az MCP weboldalon, valamint e- 
mailben tájékoztatja a vizsgázókat. Sok esetben olyan vizs- 
gákat is kihoz és felajánl, melyek segítségével teljes minő- 
sítéseket is tud frissíteni, így sokkal kevesebb vizsgát kell 
újra letennie. (Ilyen például a 070-292 és 070-296-os Win- 
dows 2003 minősítésekre frissítő vizsgák.) 

A vizsgák megszűnése után azokat letenni már nem lehet, 
a megszerzett minősítések (a Microsoft jelenlegi állásfogla- 
lása szerint) viszont továbbra is megmaradnak. (Pl. a Win- 
dows NT 4.0 minősítések még élnek, sőt ezek még akár a 
Windows 2003 minősítésekhez is felhasználhatóak). Fontos 
viszont tudni, hogy a Microsoft az egyéneknek és a cégek- 
nek is csak a legfrissebb és aktív vizsgákkal és minősíté- 
sekkel rendelkezők esetében biztosítja a minősítéssel járó 
előnyöket és lehetőségeket, tehát ezen esetekben érde- 
mes és szükséges megújítani azokat. 


További információ: 


http:// www.microsoft.com/ hun, oktaj 


A Microsoft-minősítésekhez szükséges vizsgák teljes és 
friss listája a http:/ //www.microsoft.com/traincert címen 
található. 


Ha vizsgáival, minősítésével vagy az MCP dokumentumokkal 
kapcsolatosan kérdése van, az mcphelpEemicrosoft.com 
e-mail címre írjon angol nyelvű levelet. Az e-mailben (illetve 
annak tárgyában) tüntesse fel MCP azonosítószámát, vagy 
ha ilyennel még nem rendelkezik, akkor a vizsgaközpontnál 
kapott vizsgázó azonosítóját. 


Dr VV/Vatson 


NE HIGGY A LOGNAK! 


Mármint a tűzfalak logjának. Ebben a cikkben alaposan utá- 





najárunk annak a bosszantó jelenségnek, amikor egy 





tűzfalgazda kiszúrja, hogy egy távoli IR-címről bizonyos 





"TEP-portokat , feszegetnek", vagy netalán port scanne- 


lést hajtottak végre. Azt hihetnérk, a támadó személyének 


vagy helyének felkutatására a legjobb információforrás a 





tűzfal naplófájlja. Az ottani IP-cím alapján rövid kutatást vé- 





gezve kiderül, hogy a www.érdektelen.hu webszerver a tá- 


madó, ami gazdátlanul lóg a neten, láthatóan ép és egész- 


séges, nincs feltörve. Elkövető tehát nincs. Ez hogy lehet? 


a már egyre ritkábban fordul elő, hogy egy ma- 

gányos hős sikeresen feltörne és módosítana 

egy webhelyet. Nem a hősök lettek butábbak, 
hanem a szoftverek kódja vált sokkal megbízhatóbbá, jogo- 
sultsági rendszere átgondoltabbá -— nem beszélve a sokkal 
képzettebb rendszergazdákról. Talán már nem is reális cél 
egy-egy weblap lecserélése. Úgy tűnik, a webszerverek 
read only-vá váltak még a legfelkészültebb hackerek számá- 
ra is. Ennek tudható be, hogy a hülyegyerek (script kiddie) 
kora lejárt, helyüket a professzionális adatlopók, ipari kémek 
vették át. A korkülönbség is jelentős: míg a script kiddie ma- 
ximum 16 éves, az ipari kém akár húsz is lehet! Még a leg- 
jobban védett kiszolgálókról és belső hálózatokról is renge- 
teg mindent meg lehet tudni pusztán azáltal, hogy furfangos 
kérdéseket teszünk fel nekik, ők pedig válaszolnak. Az egyik 
legismertebb információszerzési módszer a port scannelés. 


-" Select C:IWINDOWSIsystem32icmd.exe (running as BROKKOLNadministrator) HJEI 
[2] 











Egy Windows XP nyitott TCP portjai 


Rortok 

Hányas porton fut a webkiszolgáló? 80-as. És az SMTP? 25- 
ös. De mi az a port? Kikötő, kapu. Bejárat egy távoli számító- 
gép bizonyos szolgáltatása felé. Kétféle port létezik a TCP/IP 
protokollcsaládban, a kapcsolatorientált TCP (csatorna) és a 


kapcsolatmentes UDP. Minden számítógép , hallgatózik" bi- 
zonyos portokon, várja, hogy valaki megszólítsa. Az alábbi 
ábra azt mutatja meg, hogy egy hálózati kapcsolattal nem 
rendelkező, otthoni Windows XP Professional (ez a laptop, 
amin a cikket írom) mely TCP portokon , figyel". (A NetStat 
parancsot csak a helyi számítógépen tudjuk használni.) 
Néhány portot könnyedén és azonnal felismerünk az előbb 
említetteken kívül, például: 

m 135: NetbBIOS (Endpoint Mapper) 
443: SSL 
445: Windows fájl- és nyomtatómegosztás (CIFS) 
1433: MS SOL Server 
3389: Terminal Services 





Sokat tudtunk meg ezáltal a számítógépről? Majdnem min- 
dent! Ez egészen biztosan Windows, már csak a termék al- 
típusa és verziószáma kétséges. Ez utóbbi információk ki- 
derítésére speciális szerszámot szoktak használni, a port 
scannert. Egy jó port scanner ugyanis nemcsak azokat az 
adatokat dolgozza fel a válaszokból, amiket könnyű kiol- 
vasni (nyitott port itt és ott), hanem azt is, amit nehéz. Pon- 
tosan milyen TCP-válasz érkezett? Melyik mezők voltak 
benne kitöltve? Használt-e bizonyos TCP-opciókat a 
feladó? Ezek a jellegzetességek ugyanis egy adott TCP- 
implementációra vezethetők vissza, egyes esetekben 
gyártó/termék/verzió-specifikusak. . Ezt . nevezik OS 
(Operating System) fingerprintnek, az adott TCP-protokoll 
ujjlenyomatának. 


Port Scan 

Móricka úgy képzeli, hogy nekiesünk 0-tól 65535-ig az 
összes TCP és UDP portnak, és megpróbálunk kapcsola- 
tot létesíteni a távoli géppel. Ha a port nyitott, a kapcsolat 
sikeresen felépül. Ha nem - nem. Ez a , stratégia" azonban 
több sebből vérzik. 


a 














m Teljesen felesleges az összes portot kipróbálni, elég 
az úgynevezett well-known (közismert) portokat, az 
1024-ig terjedő tartományt. Ezáltal lényegesen keve- 
sebb próbálkozás elegendő. Közel ezer port nyitása 
azonban gyanús, a legtöbb tűzfal már jelenti is a gaz- 
dájának, hogy valaki , ante portas". 

mu Egy Mórickától kiinduló portkeresés tulajdonképpen 
kétirányú felderítés: Móricka megtudja a nyitott porto- 
kat, a támadott gép pedig megtudja, ki is Móricka. 


Vitathatatlan előny azonban, hogy ezt a kereséstípust tet- 
szőlegesen gyenge jogosultsággal el lehet végezni, hisz 
nincs benne semmi különleges: Móricka távoli gépekre 
csatlakozik. Ennyi. 

A modern port scannerek rengeteg kifinomult eljárást képe- 
sek használni a felderítést végző személyének és IP-címé- 
nek elrejtésére. Egyik lehetséges módszer, hogy érvényte- 
len TCP-flag kombinációkat állítanak be a kiküldött csomag- 
ban, ezáltal az áldozat megtéved, és nem veszi a portkere- 
sést annak, ami. (Furfangosan megkomponált TCP-csoma- 
gok előállítására és kiküldésére azonban már csak egy 
rendszergazda képes.) Ilyen például a Xmas Tree (F-U-P 
flagbítek beállítva), a Null Scan (egyetlen flagbit sincs beál- 
lítva) stb. De még mindig ott tartunk, hogy Móricka a saját 
gépét használja scannelésre, tehát jó eséllyel lebukik. 


Idie Scan 

A most elemzésre kerülő eljárás, az Idle Scan arra való, hogy 
egy viszonylag alig használt (Idle) ártatlan áldozat számító- 
gépet bízzunk meg a portscanneléssel. Ami történni fog, si- 
ma TCP és IP, tehát nem törünk fel semmit, ennek ellenére tet- 
szőleges Internetes számítógépet kinevezhetünk áldozatnak. 


Ég A nyitott prt H-nak válaszol! 
EREZZE ESSERE etesse 





Áldozat 


Idle host 
1. lépés vö 2. lépés 
IP Id lekérése Portscan, H IP-címével 


Támadó 





Az Idle Scan kezdeti lépései 


Először vegyük szemügyre az IP protokollt. Ennek adatstruk- 
túrájában a feladó és a célgép IP-címén kívül egy folyamato- 
san növekvő számot, az Identification mezőt figyelhetjük 
meg. Bármelyik IP-implementációt nézzük is, azt tapasztal- 
juk, hogy minden kibocsátott IP-csomagban ez a szám fo- 
lyamatosan növekszik. Most vegyük az alábbi helyzetet: 
Első lépésként a T támadó valamilyen adatot kér a H host- 
tól (mondjuk egy weblapot), de csupán azért, hogy hozzá- 
jusson annak jelenlegi IP Identification értékéhez. Majd ha- 
mis IP-címmel (H IP-címével) nekiáll portot scannelni az Á 
Áldozaton, ahol a logban H jelenik meg támadóként. Egy 
apró baj van csupán, hogy Á válaszai nem T-hez futnak be, 
mert ez már csak így van a hamisított IP-címekkel. 

Tehát van már valaki, aki tudja Á nyitott portjait, de az nem 
a Támadó, hanem a H host. 

Ha megvizsgáljuk, hogyan is reagál az Áldozat a portscan- 
nelésre, kiderül, hogy mást válaszol H-nak, ha nyitott port- 





ot találtunk el, és mást, ha zártat. A nyitott portokra eljutta- 
tott TCP (Syn) csomagra egy (Syn,Ack) válasz érkezik, ez- 
zel jelzi a szerver, hogy , jöhetsz barátom, nyitva az ajtó!". 
Ha azonban csukott porton próbálunk bemenni, kétféle 
.válasz" is várható. Egy normális operációs rendszer egy 
TCP (Rst) csomaggal válaszol (reset connection), míg egy 
tűzfal egész egyszerűen csöndben marad (nem válaszol). 
Nomármost jelen helyzetben ezek a válaszok Á-hoz futnak 
be, mit mondjak, váratlanul. Vizsgáljuk meg az eseteket! 

2. Nyitott port (Syn,Ack). Ön mit szólna, ha egyszer 
csak egy őrült odaszaladna magához, és azt monda- 
ná váratlanul, minden előzmény nélkül, hogy 
(Syn,Ack) azaz ,gyere bébi, fogjuk meg egymás ke- 
zét"? Én elküldeném melegebb éghajlatra. H tehát el- 
küldi Á-t melegebb éghajlatra (Rst). Nem mellesleg 
ezzel megnöveli az IP Identification számlálóját, hisz 
minden kiküldött csomag esetén növeli eggyel. 

3. Csukott port (csend, vagy Rst). Ha H nem kap sem- 
mit, nem is válaszol semmit. Szerencsére szintén 
nem válaszol egy , eltévedt" (Rst) csomagra sem. 

Foglaljuk össze: 

m Ha nyitott portot találtunk el Á-n, az IP Id mező eggyel 
növekedett H-n 

m Ha zárt portot kérdeztünk Á-n, az IP Id változatlan 
maradt H-n 

Már csak le kell kérdeznünk H-ról az IP Id aktuális értékét. 
Ha eggyel nagyobbat kapunk, mint először, az annyit je- 
lent, hogy csukott portot tapogattunk Á-n, mivel a --1 a mi 
válaszcsomagunk lda-je. Ha kettővel növelt értéket kapunk, 
Á-n nyitott portot találtunk el, oda is küldött csomagot H. 
Most már azt is látjuk, miért kell egy viszonylag csendes, 
senki által nem látogatott host ehhez a keresési eljáráshoz. 
Ha valaki egy népszerű, napi tízezer találatot kapó webhe- 
lyet próbál H-ként használni, az IP Id értéke nem marad 
veszteg, hanem folyamatosan pörög. (Csendes gépet kön- 
nyebb találni, mint terheltet!) 


NMapWin 

Az Idle Scan kivitelezéséhez kész eszközöket találunk a 
neten. A www.insecure.org-ról letölthető, egyébként linux- 
os NMap-ból már van Windowsos változat, az NMapWin. 
Ezzel gyerekjáték az Idle Scan kivitelezése, aki tud válasz- 
tani egy opciót és be tud pipálni egy jelölőnégyzetet, annak 
ez nem okozhat gondot. 
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Ezerféle Port Scan az NMapban, köztük az 
Idie Scan 


A maradék 10-12 portkeresési üzemmód megismerése há- 
zi feladat! 

Főri MARCELL 

marcellfinnetacademia. net 

MCT. MCSE. MCDBA, MZ/X 
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Nyári gyorsított MCSA képzés 
júliusban a NetAcademiánaál 
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2273 - Managing and Maintaining 
a Microsoft Windows Server 2003 
Environment 

Időpont: 2004. július 12-16. 


2276/2277 - Implementing, Managing 
and Maintaining a Windows 2003 
Server Network Infrastructure 

Időpont: 2004. július 19-23. 


2285 - Installing, Configuring, and 
Administering Microsoft Windows 
XP Professional 

Időpont: 2004. július 5-6. 


2159 - Deploying and Managing 
Microsoft Internet Security and 
Acceleration (ISA) Server 2000 

Időpont: 2004. július 7-9. 





A tanfolyamcsomag kedvezményes ára: 380.000 Ft-ráfa 





Az ár nem tartalmazza a vizsgák díját! A kedvezmény csak a 4 tanfolyam együttes megrendelése esetén érvényes! 


máciÓó nforgnetacademia.ne 1)472-1214 wn netacademia.net 
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